From owner-freebsd-stable@FreeBSD.ORG Sun Apr 7 12:58: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 2A52F7C3; Sun, 7 Apr 2013 12:58:30 +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 D7B7FAFD; Sun, 7 Apr 2013 12:58:29 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1UOpAo-0006ee-UT; Sun, 07 Apr 2013 15:58:19 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Andriy Gapon Subject: Re: panic: vm_fault_copy_wired: page missing In-reply-to: <516066BF.90103@FreeBSD.org> References: <516066BF.90103@FreeBSD.org> Comments: In-reply-to Andriy Gapon message dated "Sat, 06 Apr 2013 21:17:35 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 07 Apr 2013 15:58:18 +0300 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: Sun, 07 Apr 2013 12:58:30 -0000 > on 05/04/2013 12:33 Daniel Braniss said the following: > > The system is running FreeBSD-9.1-stable, and is dataless/diskless. > > the culprit is mlockall(2) which is called from the automounter amd/am-utils, > > commenting the call, eliminates the panic. > > > > I don't know when the problem surfaced, I was last hit by this > > 2 years ago almost to the day - creepy. > > > > I can make this happen by first running firefox, and the trying some > > command that involves the automounter. > > > > so is someone interested in fixing this? > > So, is there someone interested in properly reporting the problem first? > :-) since it seems to be happening only to me, I wasn't sure if it was a good idea writing a long message with allot of info that noone would read :-) so, in the meantime, some more info: when the root file system is NOT via NFS all seems ok, when the root is via NFS, no matter is amd is via NFS or not, it panics: panic: vm_fault_copy_wired: page missing cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffff814907a790 kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff814907a850 panic() at panic+0x1ce/frame 0xffffff814907a950 vm_fault_copy_entry() at vm_fault_copy_entry+0x28e/frame 0xffffff814907a9e0 vmspace_fork() at vmspace_fork+0x553/frame 0xffffff814907aa30 fork1() at fork1+0x328/frame 0xffffff814907aae0 sys_fork() at sys_fork+0x22/frame 0xffffff814907ab10 amd64_syscall() at amd64_syscall+0x540/frame 0xffffff814907ac30 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xffffff814907ac30 --- syscall (2, FreeBSD ELF64, sys_fork), rip = 0x800edd36c, rsp = 0x7fffffffd0c8, rbp = 0 --- #0 doadump (textdump=1) at /r+d/stable/9/sys/kern/kern_shutdown.c:266 #1 0xffffffff809022b4 in kern_reboot (howto=260) at /r+d/stable/9/sys/kern/kern_shutdown.c:449 #2 0xffffffff809027a7 in panic (fmt=0x1
) at /r+d/stable/9/sys/kern/kern_shutdown.c:637 #3 0xffffffff80b62e6e in vm_fault_copy_entry (dst_map=0xfffffe001270adc8, src_map=, dst_entry=0xfffffe0012bc2348, src_entry=, fork_charge=) at /r+d/stable/9/sys/vm/vm_fault.c:1356 #4 0xffffffff80b6bb73 in vmspace_fork (vm1=0xfffffe000de90498, fork_charge=0xffffff814907aaa8) at /r+d/stable/9/sys/vm/vm_map.c:3035 #5 0xffffffff808d1828 in fork1 (td=0xfffffe00122d3920, flags=20, pages=4, procp=0xffffff814907ab00, procdescp=, pdflags=) at /r+d/stable/9/sys/kern/kern_fork.c:841 #6 0xffffffff808d3272 in sys_fork (td=0xfffffe00122d3920, uap=) at /r+d/stable/9/sys/kern/kern_fork.c:110 #7 0xffffffff80c8f330 in amd64_syscall (td=0xfffffe00122d3920, traced=0) at subr_syscall.c:135 #8 0xffffffff80c79a17 in Xfast_syscall () at /r+d/stable/9/sys/amd64/amd64/exception.S:387 #9 0x0000000800edd36c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) cheers danny > > -- > Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sun Apr 7 21:35: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 5B81856B; Sun, 7 Apr 2013 21:35:24 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail4out.barnet.com.au (mail4out.barnet.com.au [202.83.178.123]) by mx1.freebsd.org (Postfix) with ESMTP id 1DE96111; Sun, 7 Apr 2013 21:35:23 +0000 (UTC) Received: from localhost (antivirus11.int.barnet.com.au [10.252.48.18]) by mail4out.barnet.com.au (Postfix) with ESMTP id AC8CF37BB28; Mon, 8 Apr 2013 07:27:03 +1000 (EST) X-Virus-Scanned: Debian amavisd-new at barnet.com.au Received: from mail4.barnet.com.au ([202.83.178.125]) by localhost (antivirus11.int.barnet.com.au [10.252.48.18]) (amavisd-new, port 10024) with ESMTP id 6jkBtcNQvFII; Mon, 8 Apr 2013 07:27:02 +1000 (EST) Received: from mail4auth.barnet.com.au (mail4.barnet.com.au [202.83.178.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.barnet.com.au", Issuer "RapidSSL CA" (not verified)) by mail4.barnet.com.au (Postfix) with ESMTPS id 3ACEE42318A; Mon, 8 Apr 2013 07:27:02 +1000 (EST) Received: from Edwin-Groothuiss-Mac-mini.local (ppp121-44-145-35.lns20.syd7.internode.on.net [121.44.145.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail4auth.barnet.com.au (Postfix) with ESMTPSA id DB6AF37BB1E; Mon, 8 Apr 2013 07:27:01 +1000 (EST) Message-ID: <5161E4A5.8040200@mavetju.org> Date: Mon, 08 Apr 2013 07:27:01 +1000 From: Edwin Groothuis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Claude Buisson Subject: Re: Why tzdata2013b has not be merged to stable/8 ? References: <515BF29B.9000701@orange.fr> In-Reply-To: <515BF29B.9000701@orange.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, edwin@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, 07 Apr 2013 21:35:24 -0000 On 3/04/13 20:12 , Claude Buisson wrote: > On March 15, tzdata2013b has been merged to head (r248307), to stable/6 > (r248308), to stable/7 (r248309) and to stable/9 (r248310). > > But not to stable/8. I did not see it going wrong, but I assume it was because stable/8 is in a freeze right now. I'll drop an email to re@ to get approval. Edwin From owner-freebsd-stable@FreeBSD.ORG Mon Apr 8 10:02: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 06BD2135 for ; Mon, 8 Apr 2013 10:02:40 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by mx1.freebsd.org (Postfix) with ESMTP id C12B8FA4 for ; Mon, 8 Apr 2013 10:02:39 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id kw10so2477505vcb.5 for ; Mon, 08 Apr 2013 03:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=J09SVUg/F94dlb97ePKPV+EEJISv6Kcm0OacwHEbGM8=; b=Za2vv0DypvlXm7U+brsuiHnncKNOsRDQCO+CF6OsEjlsWbgxTHONbUhB1rGdHhJu1n 6U3t4BT8OPZ1ofkOD9jzpi50Wkl+dmDq9W6BgYGUg4Yqb56k2bSjOh6TqBspRb9MKN+i PQmGEm7Qn2BMi/MNgmvZikhTrN5L9+3phBtoMm4wkcbHFjKz6NtINRAOA9rOejRxgz2c EWPBfk5AQYeCrt5f2ItIDSXiBmnw/yP9+SBYpacYlNRbUNnOrWDgYqLiNokqzEmHwdbr iIZmy3Vo9ZvcsAFIPE0tlFbaKHyNJKan6IpliBuHrdKseN74hEFmqYobIGjx44nZlwSm 8VaQ== MIME-Version: 1.0 X-Received: by 10.220.222.8 with SMTP id ie8mr15420173vcb.27.1365415358729; Mon, 08 Apr 2013 03:02:38 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Mon, 8 Apr 2013 03:02:38 -0700 (PDT) Date: Mon, 8 Apr 2013 03:02:38 -0700 Message-ID: Subject: FreeBSD Releases *.ISO Information From: Mehmet Erol Sanliturk To: freebsd-stable Content-Type: text/plain; charset=UTF-8 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: Mon, 08 Apr 2013 10:02:40 -0000 Dears All , In no one of the following directories : ftp://ftp1.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/8.3/ ftp://ftp1.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/8.4/ ftp://ftp1.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/ ftp://ftp1.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.1/ there is a "read me" file to describe *.iso files and how to use them . For experienced users , such a file may be "nonsense" , but each year , there are a lot of "NEW" candiate users grown sufficently in age which many of them may wish to try any of the *.iso files . When there is no any information about them , what can they do ? There is a file in their parent directory : ftp://ftp1.freebsd.org/pub/FreeBSD/releases/README.TXT This file may contain such a descriptive information . Preparing a .html file with links to information about how to burn / record these files may be much more useful : It may contain links to : http://www.freebsd.org/where.html In the above page , there is ONLY a link to the following : http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install.html ( Chapter 3 Installing FreeBSD 8.X and Earlier ) Inclusion of link to the following page may be useful : http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/bsdinstall.html ( Chapter 2 Installing FreeBSD 9.X and Later ) http://www.freebsd.org/releases/9.1R/installation.html : The above page does not contain any information about *.iso files . Some sample pages : http://www.sysresccd.org/Sysresccd-manual-en_How_to_install_SystemRescueCd_on_an_USB-stick http://www.sysresccd.org/Sysresccd-manual-en_Downloading_and_burning http://www.ubuntu.com/download/desktop http://www.ubuntu.com/download/help/try-ubuntu-before-you-install http://www.ubuntu.com/download/help/burn-a-dvd-on-windows http://www.ubuntu.com/download/help/create-a-usb-stick-on-windows http://www.ubuntu.com/download/help/install-ubuntu-with-windows http://www.ubuntu.com/download/help/burn-a-dvd-on-ubuntu http://www.ubuntu.com/download/help/create-a-usb-stick-on-ubuntu Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-stable@FreeBSD.ORG Mon Apr 8 10:45: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 69A96AE9 for ; Mon, 8 Apr 2013 10:45:36 +0000 (UTC) (envelope-from fabian@wenks.ch) Received: from batman.home4u.ch (batman.home4u.ch [IPv6:2001:8a8:1005:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id D84CE222 for ; Mon, 8 Apr 2013 10:45:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at home4u.ch Received: from flashback.wenks.ch (fabian@flashback.wenks.ch [IPv6:2001:8a8:1005:1:223:dfff:fedf:13c9]) (authenticated bits=0) by batman.home4u.ch (8.14.5/8.14.5) with ESMTP id r38AjXfM042026 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 8 Apr 2013 12:45:33 +0200 (CEST) (envelope-from fabian@wenks.ch) Message-ID: <51629FCD.8060808@wenks.ch> Date: Mon, 08 Apr 2013 12:45:33 +0200 From: Fabian Wenk User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: FreeBSD Releases *.ISO Information 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: Mon, 08 Apr 2013 10:45:36 -0000 Hello Mehmet Erol On 08.04.2013 12:02, Mehmet Erol Sanliturk wrote: > there is a "read me" file to describe *.iso files and how to use them . > When there is no any information about them , what can they do ? For example in the announcement for the release, e.g. here [1] for FreeBSD 9.1 [1] http://www.freebsd.org/releases/9.1R/announce.html#availability bye Fabian From owner-freebsd-stable@FreeBSD.ORG Mon Apr 8 11:32: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 B0647EAB for ; Mon, 8 Apr 2013 11:32:47 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by mx1.freebsd.org (Postfix) with ESMTP id 75B7086B for ; Mon, 8 Apr 2013 11:32:47 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id m16so391549vca.25 for ; Mon, 08 Apr 2013 04:32:40 -0700 (PDT) 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=edJ+zp2cy18Dwrv/dqqgnfJjW6ZBjAbyrIWzvt5zUGs=; b=nOAIv7+z5Geg+t9mo2k1ohhzo3I2GJLXjxjTdSvudsCClnKxrD+uJfQhsPp20DMEUD R7zBESwOGn7Bbje3EJbhyG6I7OjIMalE7u0Imh6tIkRlfU88/fudu/4oRA9K2/Wxi5O+ FCrE99jiToOmuyGkOTMwZ/vWy8cwhAuGSGbHz/FvF6FqDs0YugCJ8SbizIU3/+w0GMlq yB/bur/I0a0yGuJFEXhCfY6NttEaVCsiQjSJ+SDYnbOZ1RxIF65vWJOPOUAIK7ZOkRXo +LJOoNsn0dSvept+G9gePKIvAs/wxHHmrOXTajtl0HPX7iwvES09vc0wXQ6Ow+ahUlt7 o/LQ== MIME-Version: 1.0 X-Received: by 10.52.68.116 with SMTP id v20mr12974952vdt.126.1365420760734; Mon, 08 Apr 2013 04:32:40 -0700 (PDT) Received: by 10.58.132.203 with HTTP; Mon, 8 Apr 2013 04:32:40 -0700 (PDT) In-Reply-To: <51629FCD.8060808@wenks.ch> References: <51629FCD.8060808@wenks.ch> Date: Mon, 8 Apr 2013 04:32:40 -0700 Message-ID: Subject: Re: FreeBSD Releases *.ISO Information From: Mehmet Erol Sanliturk To: Fabian Wenk Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: 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: Mon, 08 Apr 2013 11:32:47 -0000 Information in that page may be moved into a page in the respective directory , and release announcements and other pages may have a link to that page . In that way , both requirements may be fulfilled . Main goal is to enable the new users to reach to related information in the shortest possible way . Thank you very much . Mehmet Erol Sanliturk On Mon, Apr 8, 2013 at 3:45 AM, Fabian Wenk wrote: > Hello Mehmet Erol > > On 08.04.2013 12:02, Mehmet Erol Sanliturk wrote: > > there is a "read me" file to describe *.iso files and how to use them . >> > > When there is no any information about them , what can they do ? >> > > For example in the announcement for the release, e.g. here [1] for FreeBSD > 9.1 > > [1] http://www.freebsd.org/**releases/9.1R/announce.html#**availability > > > bye > Fabian > ______________________________**_________________ > 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 Apr 9 02:27: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 A1A5E9B5 for ; Tue, 9 Apr 2013 02:27:05 +0000 (UTC) (envelope-from damonray@mac.hush.com) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by mx1.freebsd.org (Postfix) with ESMTP id 874809F1 for ; Tue, 9 Apr 2013 02:27:05 +0000 (UTC) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id 30CE530351 for ; Tue, 9 Apr 2013 01:56:43 +0000 (UTC) Received: from smtp.hushmail.com (w4.hushmail.com [65.39.178.50]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Tue, 9 Apr 2013 01:56:43 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 0817D10E2C8; Tue, 9 Apr 2013 01:56:42 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 08 Apr 2013 20:56:42 -0500 To: freebsd-stable@freebsd.org Subject: Ghosted logins in w/who From: damonray@mac.hush.com Message-Id: <20130409015643.0817D10E2C8@smtp.hushmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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, 09 Apr 2013 02:27:05 -0000 I recently upgraded to FreeBSD 9.1-STABLE, and there was a strange added side effect. Users that telnet into the machine seem to have their logins forever ghosted in who/w. If a user connects via telnet, then logs out, their login still remains in the w/who. If another user logins in with the pty they had, whatever they do also shows up in the ghosted w/who of the previous user using that pty. For example: User X logs in, runs BitchX. Detaches the process and logs out.User Y logs in, gets assigned User X's previous pty, who/w now reports that user is running BitchX. That user has no access to the BitchX session or anything, it's just being displayed weird in who/w. I seem to remember this problem like a decade ago and I had written a script or there was a script that passed around called clearlogin. Any ideas? Thanks all!Damon From owner-freebsd-stable@FreeBSD.ORG Tue Apr 9 02:28: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 D0AF6BC9 for ; Tue, 9 Apr 2013 02:28:38 +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 AF439A46 for ; Tue, 9 Apr 2013 02:28:38 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta01.emeryville.ca.mail.comcast.net with comcast id Mc0a1l00J1smiN4A1eUeG4; Tue, 09 Apr 2013 02:28:38 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta20.emeryville.ca.mail.comcast.net with comcast id MeUd1l0061t3BNj8geUdD6; Tue, 09 Apr 2013 02:28:37 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 39BCE73A39; Mon, 8 Apr 2013 19:28:37 -0700 (PDT) Date: Mon, 8 Apr 2013 19:28:37 -0700 From: Jeremy Chadwick To: damonray@mac.hush.com Subject: Re: Ghosted logins in w/who Message-ID: <20130409022837.GA95155@icarus.home.lan> References: <20130409015643.0817D10E2C8@smtp.hushmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130409015643.0817D10E2C8@smtp.hushmail.com> 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=1365474518; bh=N0YrGEbLFaig5NDeAvFxLYQniyRikeI6dkKHvWJiMug=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=O3w+Yy/l70vZ/8RqpAfIqul82ixIEAlr8a5gLTGdJkINFU4Yt2HtfRRLjowT+7Ro+ cVXGSHYb8FiBLyHdukWKz1AdqMIVgDCQ/H5ZsKJsiEzzMaA7u68YLOgIpgZl+NhjF8 VtI6+5qUPPRMQ3iexN4hVyYH5jpeUqD6AXh3IjjXqTgdN1XSydTqBx8pdvcn2hMhU6 6jjM8Pry6zE0f6AIdFKbR1n3amESi8l9ToFoPph6sNq5qVhjav2e1S77I0eIAZ7NHW rDJGVwHVesu91+zpTPAsHAnVdw4Dfne+3W5RFROmZTIAwIN5z/a6A3RbcWSCcsV0Mh nxWT1D7QzyEhw== 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, 09 Apr 2013 02:28:38 -0000 On Mon, Apr 08, 2013 at 08:56:42PM -0500, damonray@mac.hush.com wrote: > I recently upgraded to FreeBSD 9.1-STABLE, and there was a strange > added side effect. > Users that telnet into the machine seem to have their logins forever > ghosted in who/w. > If a user connects via telnet, then logs out, their login still > remains in the w/who. If another user logins in with the pty they had, > whatever they do also shows up in the ghosted w/who of the previous > user using that pty. > For example: > User X logs in, runs BitchX. Detaches the process and logs out.User Y > logs in, gets assigned User X's previous pty, who/w now reports that > user is running BitchX. That user has no access to the BitchX session > or anything, it's just being displayed weird in who/w. > I seem to remember this problem like a decade ago and I had written a > script or there was a script that passed around called clearlogin. > Any ideas? Thanks all!Damon Is GNU screen involved? It sounds like it. Try to repeat the problem without GNU screen. -- | 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 Tue Apr 9 10:07:39 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 565B89C for ; Tue, 9 Apr 2013 10:07:39 +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 0F711EA9 for ; Tue, 9 Apr 2013 10:07:38 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1UPVSY-0005Hj-Jm; Tue, 09 Apr 2013 13:07:26 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Jeremy Chadwick Subject: Re: Ghosted logins in w/who In-reply-to: <20130409022837.GA95155@icarus.home.lan> References: <20130409015643.0817D10E2C8@smtp.hushmail.com> <20130409022837.GA95155@icarus.home.lan> Comments: In-reply-to Jeremy Chadwick message dated "Mon, 08 Apr 2013 19:28:37 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Apr 2013 13:07:26 +0300 From: Daniel Braniss Message-ID: Cc: damonray@mac.hush.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: Tue, 09 Apr 2013 10:07:39 -0000 > On Mon, Apr 08, 2013 at 08:56:42PM -0500, damonray@mac.hush.com wrote: > > I recently upgraded to FreeBSD 9.1-STABLE, and there was a strange > > added side effect. > > Users that telnet into the machine seem to have their logins forever > > ghosted in who/w. > > If a user connects via telnet, then logs out, their login still > > remains in the w/who. If another user logins in with the pty they had, > > whatever they do also shows up in the ghosted w/who of the previous > > user using that pty. > > For example: > > User X logs in, runs BitchX. Detaches the process and logs out.User Y > > logs in, gets assigned User X's previous pty, who/w now reports that > > user is running BitchX. That user has no access to the BitchX session > > or anything, it's just being displayed weird in who/w. > > I seem to remember this problem like a decade ago and I had written a > > script or there was a script that passed around called clearlogin. > > Any ideas? Thanks all!Damon > > Is GNU screen involved? It sounds like it. > > Try to repeat the problem without GNU screen. something changed beteen 8 and 9 with respect of handling of utmp, I tried to research this but got bogged down with other things. danny From owner-freebsd-stable@FreeBSD.ORG Tue Apr 9 11:00: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 6A4D2B98 for ; Tue, 9 Apr 2013 11:00:45 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 1480D15A for ; Tue, 9 Apr 2013 11:00:44 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r39B0fow003964 for ; Tue, 9 Apr 2013 18:00:41 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5163F4D4.1090505@rdtc.ru> Date: Tue, 09 Apr 2013 18:00:36 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: FreeBSD Stable Subject: Release ISO images have broken RockRidge data 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: Tue, 09 Apr 2013 11:00:45 -0000 Hi! Release ISO images located at ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ISO-IMAGES/ were generated with mkisofs until switch to makefs. For example, ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ISO-IMAGES/8.2/FreeBSD-8.2-RELEASE-amd64-livefs.iso was generated with mkisofs and has correct RockRidge extended attributes. # isoinfo -d -R -i FreeBSD-8.2-RELEASE-amd64-livefs.iso System id: FreeBSD Volume id: FreeBSD_LiveFS Volume set id: Publisher id: The FreeBSD Project. http://www.freebsd.org/ Data preparer id: Application id: MKISOFS ISO 9660/HFS FILESYSTEM BUILDER & CDRECORD CD-R/DVD CREATOR (C) 1993 E.YOUNGDALE (C) 1997 J.PEARSON/J.SCHILLING Copyright File id: Abstract File id: Bibliographic File id: Rock Ridge signatures version 1 found Rock Ridge id 'RRIP_1991A' Eltorito validation header: Hid 1 Bootid 88 (bootable) This image may be unrolled correctly with respect to hardlinks using xorriso command from ports: # xorriso -for_backup -load volid \* -indev ../FreeBSD-8.2-RELEASE-amd64-livefs.iso -osirrox on -- -extract / livefs -rollback_end Newer images (8.3 and later) were generated using makefs that seem to produce incorrect RockRidge data: # isoinfo -d -R -i FreeBSD-8.4-BETA1-amd64-livefs.iso | grep id System id: NetBSD Volume id: FREEBSD_LIVEFS Volume set id: Publisher id: Data preparer id: Application id: Copyright File id: Abstract File id: Bibliographic File id: Rock Ridge signatures version 1 found Rock Ridge id 'IEEE_P1282' Eltorito validation header: Hid 1 Bootid 88 (bootable) Same xorriso command produces tons of following error messages and unrolls the image without respect to hardlinkg increasing size in nearly 3 times: libisofs: WARNING : Invalid TF entry Caused by: Wrong or damaged RR entry bsdtar from 8.3-STABLE shows lots of errors too, while extracting FreeBSD-8.4-BETA1-amd64-livefs.iso mdconfig breaks hardlinks too. Is it possible to unroll this image respecting hardlinks? Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Tue Apr 9 12:50:39 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 F04B73A3 for ; Tue, 9 Apr 2013 12:50:38 +0000 (UTC) (envelope-from christian.baer@uni-dortmund.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 864AF860 for ; Tue, 9 Apr 2013 12:50:37 +0000 (UTC) Received: from lianli4.localnet (p5099ba30.dip0.t-ipconnect.de [80.153.186.48]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0LoekB-1V6JXZ3ump-00glXU; Tue, 09 Apr 2013 14:50:31 +0200 From: Christian Baer To: freebsd-stable@freebsd.org Subject: -Os breaks buildworld Date: Tue, 09 Apr 2013 14:50:29 +0200 Message-ID: <3845278.lKnuOXNTV5@lianli4> User-Agent: KMail/4.7.2 (Linux/3.1.10-1.19-desktop; KDE/4.7.2; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V02:K0:CArNWOKVk1TERG3v86JGwyQuoebVlbmQdBLbt/YOSaG 6CEuRxkX65mcCJ5ZKJfCTJ31O/0G5VQW68Xy1QqM8WsKLOywDJ 4t0zr50qstvt58WwFXMZu2pS5oKTS/BCWVonB9bc4ZlyNnqVJm UQ+5rnkNBJFKBDlbtwk81l1IL839yJ/GR4aUgxxRs/zXhgocOz +61NMrQH64U4YjiCsfMj5+UDPOmUoHzv1IM6LaDC9su6CKFbJe obKBpsf3rFO2KewuHSMQzM4prGCw3vvG2s76slmJ7ecYU7K6MX mewTG1iZnapuMF8QIeBqSELVlmcy3aUmPbsTTKI6U2LQ5AO3ui a1bIX52cF/49zNMHvC4g= 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, 09 Apr 2013 12:50:39 -0000 Hey everyone! This is not really an important issue, I just wanted to find out if anyone had it on his or her radar. I have a machine that isn't too powerful and hasn't got a lot of RAM either. So as an experiment I wanted to compile the world with the option for conserving space. Unfortunately, that didn't work out too well as it broke the compile (see last lines appended after my signature). I updated with svn to version 249301 before compiling. The same code compiled with O2 works fine. I know you are going to ask about my CFLAGS, so here they are: CPUTYPE= athlon-xp CFLAGS= -O2 -fno-strict-aliasing -pipe -mtune=athlon-xp -march=athlon-xp And yes, the CPU is really an Athlon XP. ;-) The only change I need to make to break the compile is -O2 to -Os. Has anyone noticed this too? Best regards, Chris famous last lines... :-) cc -Os -fno-strict-aliasing -pipe -mtune=athlon-xp -march=athlon-xp -march=athlon-xp -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -DSYSCALL_COMPAT -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libthr/sys/thr_error.c cc -Os -fno-strict-aliasing -pipe -mtune=athlon-xp -march=athlon-xp -march=athlon-xp -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 -I/usr/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -DSYSCALL_COMPAT -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libthr/thread/thr_affinity.c cc1: warnings being treated as errors /usr/src/lib/libthr/thread/thr_affinity.c: In function '_pthread_setaffinity_np': /usr/src/lib/libthr/thread/thr_umtx.h:103: warning: inlining failed in call to '_thr_umutex_unlock': --param max-inline-insns-single limit reached /usr/src/lib/libthr/thread/thr_affinity.c:56: warning: called from here /usr/src/lib/libthr/thread/thr_umtx.h:103: warning: inlining failed in call to '_thr_umutex_unlock': --param max-inline-insns-single limit reached /usr/src/lib/libthr/thread/thr_affinity.c:64: warning: called from here *** Error code 1 Stop in /usr/src/lib/libthr. *** Error code 1 Stop in /usr/src. *** Error code 1 From owner-freebsd-stable@FreeBSD.ORG Tue Apr 9 13:22:40 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 B5361F64 for ; Tue, 9 Apr 2013 13:22:40 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 7A55D9F7 for ; Tue, 9 Apr 2013 13:22:40 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id j3so1134249qcs.34 for ; Tue, 09 Apr 2013 06:22:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:references:from:content-type:x-mailer :in-reply-to:message-id:date:to:content-transfer-encoding :mime-version:x-gm-message-state; bh=3CUlYDqzk1s1gXvY0OeemdtcXEp8EVaR+oWrk6VDyUo=; b=Yn4dC89o68IRS2YBXwdCMg/O/raxldlPgVsacao5Tp/EQM1dSbjm+Netsk1c2HTHQ9 O85VXGVwiMSktOrJpeaGITP8qoS5gJbUHLJSlzj8HZKBTI19oM3BIczvKOeAsgxcMhwM QBeYduraHg0ut8BvWnrACvIYgL8pe6YGtEMJZgUDlAvL5EaOz1ApZldUbfsfzwjEvjrX vBRIN7g2L252SDuIqhjfg5Al0GbJv3ZWHN7E5Plq2Dyi/E8QS5mbfryGfC90bFQdJdVE zB2WWGHQe/HfJlZzLs9VeQJV0Prxq9z720V/piI/27Iq3TA8JjsurcuZHyj9YpDuE6jo fUcg== X-Received: by 10.49.74.71 with SMTP id r7mr11494522qev.52.1365513759940; Tue, 09 Apr 2013 06:22:39 -0700 (PDT) Received: from [97.241.117.81] (81.sub-97-241-117.myvzw.com. [97.241.117.81]) by mx.google.com with ESMTPS id m8sm16835543qav.8.2013.04.09.06.22.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 06:22:39 -0700 (PDT) Subject: Re: Release ISO images have broken RockRidge data References: <5163F4D4.1090505@rdtc.ru> From: Mark Saad Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (10B329) In-Reply-To: <5163F4D4.1090505@rdtc.ru> Message-Id: <5FD2125C-678B-4DCB-B9ED-33C0D3AB2B81@longcount.org> Date: Tue, 9 Apr 2013 09:21:52 -0400 To: FreeBSD Stable Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Gm-Message-State: ALoCoQmVni6dIk6A6Li8+3JgSg6T8tpEi+8nHENzh3Gw7Q/I53QT6ur3z/OUEgKB9n0Q3uDMz91i 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, 09 Apr 2013 13:22:40 -0000 On Apr 9, 2013, at 7:00 AM, Eugene Grosbein wrote: > Hi! >=20 > Release ISO images located at ftp://ftp.freebsd.org/pub/FreeBSD/releases/a= md64/ISO-IMAGES/ > were generated with mkisofs until switch to makefs. For example, > ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ISO-IMAGES/8.2/FreeBSD-8.= 2-RELEASE-amd64-livefs.iso > was generated with mkisofs and has correct RockRidge extended attributes. >=20 > # isoinfo -d -R -i FreeBSD-8.2-RELEASE-amd64-livefs.iso > System id: FreeBSD > Volume id: FreeBSD_LiveFS > Volume set id:=20 > Publisher id: The FreeBSD Project. http://www.freebsd.org/ > Data preparer id:=20 > Application id: MKISOFS ISO 9660/HFS FILESYSTEM BUILDER & CDRECORD CD-R/DV= D CREATOR (C) 1993 E.YOUNGDALE (C) 1997 J.PEARSON/J.SCHILLING > Copyright File id:=20 > Abstract File id:=20 > Bibliographic File id:=20 > Rock Ridge signatures version 1 found > Rock Ridge id 'RRIP_1991A' > Eltorito validation header: > Hid 1 > Bootid 88 (bootable) >=20 > This image may be unrolled correctly with respect to hardlinks using xorri= so command from ports: >=20 > # xorriso -for_backup -load volid \* -indev ../FreeBSD-8.2-RELEASE-amd64-l= ivefs.iso -osirrox on -- -extract / livefs -rollback_end >=20 > Newer images (8.3 and later) were generated using makefs that seem to prod= uce incorrect RockRidge data: >=20 > # isoinfo -d -R -i FreeBSD-8.4-BETA1-amd64-livefs.iso | grep id > System id: NetBSD > Volume id: FREEBSD_LIVEFS > Volume set id:=20 > Publisher id:=20 > Data preparer id:=20 > Application id:=20 > Copyright File id:=20 > Abstract File id:=20 > Bibliographic File id:=20 > Rock Ridge signatures version 1 found > Rock Ridge id 'IEEE_P1282' > Eltorito validation header: > Hid 1 > Bootid 88 (bootable) >=20 > Same xorriso command produces tons of following error messages and unrolls= the image > without respect to hardlinkg increasing size in nearly 3 times: >=20 > libisofs: WARNING : Invalid TF entry > Caused by: Wrong or damaged RR entry >=20 > bsdtar from 8.3-STABLE shows lots of errors too, while extracting FreeBSD-= 8.4-BETA1-amd64-livefs.iso > mdconfig breaks hardlinks too. >=20 > Is it possible to unroll this image respecting hardlinks? >=20 > Eugene Grosbein >=20 While not the same you can always do this=20 mdconfig -a -t vnode -f yourfreebsd-version.iso mount -t cd9660 /dev/md0 /cdrom=20 Then use pax, cpio , cp, rsync etc to copy the data off the image . Also if memory serves me right libarchive may be able to unpack an iso much l= ike a tar or cpio archive . Double check that .=20 Also makefs was imported from netbsd I would see if netbsd's isos have the s= ame issues .=20 Hope this helps=20 --- Mark saad | mark.saad@longcount.org From owner-freebsd-stable@FreeBSD.ORG Tue Apr 9 14:42: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 B899CFEF for ; Tue, 9 Apr 2013 14:42:30 +0000 (UTC) (envelope-from fabian@wenks.ch) Received: from batman.home4u.ch (batman.home4u.ch [IPv6:2001:8a8:1005:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4C68DEBB for ; Tue, 9 Apr 2013 14:42:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at home4u.ch Received: from flashback.wenks.ch (fabian@flashback.wenks.ch [IPv6:2001:8a8:1005:1:223:dfff:fedf:13c9]) (authenticated bits=0) by batman.home4u.ch (8.14.5/8.14.5) with ESMTP id r39EgRL4037357 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 9 Apr 2013 16:42:27 +0200 (CEST) (envelope-from fabian@wenks.ch) Message-ID: <516428D2.9020701@wenks.ch> Date: Tue, 09 Apr 2013 16:42:26 +0200 From: Fabian Wenk User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Ghosted logins in w/who References: <20130409015643.0817D10E2C8@smtp.hushmail.com> <20130409022837.GA95155@icarus.home.lan> 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, 09 Apr 2013 14:42:30 -0000 Hello Daniel On 09.04.2013 12:07, Daniel Braniss wrote: > something changed beteen 8 and 9 with respect of handling of utmp, > I tried to research this but got bogged down with other things. According to /usr/src/UPDATING: 20100113: The utmp user accounting database has been replaced with utmpx, the user accounting interface standardized by POSIX. Unfortunately the semantics of utmp and utmpx don't match, making it practically impossible to support both interfaces. The user accounting database is used by tools like finger(1), last(1), talk(1), w(1) and ac(8). All applications in the base system use utmpx. This means only local binaries (e.g. from the ports tree) may still use these utmp database files. These applications must be rebuilt to make use of utmpx. After the system has been upgraded, it is safe to remove the old log files (/var/run/utmp, /var/log/lastlog and /var/log/wtmp*), assuming their contents is of no importance anymore. Old wtmp databases can only be used by last(1) and ac(8) after they have been converted to the new format using wtmpcvt(1). Could this have any impact regarding this issue with telnet login? bye Fabian From owner-freebsd-stable@FreeBSD.ORG Tue Apr 9 14:58: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 5C30C3B5 for ; Tue, 9 Apr 2013 14:58:21 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by mx1.freebsd.org (Postfix) with ESMTP id ED202FA7 for ; Tue, 9 Apr 2013 14:58:20 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id z11so311665wgg.11 for ; Tue, 09 Apr 2013 07:58:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:content-type:x-gm-message-state; bh=3D8BHbjFuXuoQwDgfnnYiJ1+wsoLTQuAfTOJPZ4KWGk=; b=E0hD/rtZB4P3gWReoTGJrq9cHt3c6zNnTrL2bfUgTTZ3FS5yXgjinQqaet11DurUjR 4n5CzvAOkS8MX8+7YNVMEGiuZb0Oek8lI2zZU/Yn7lauReDXsIzi5BPz8Det24kSHuJi RNY23cL+rwYinqXjrw5WNtJVhgAyU+bIaLjPuhKwvdZEfcjmmionGU/d+P13+sUZtaEl Q9yc+XCKOwHIeNb79qWwRR3FN9NnY1gSfveS7LO84HB7Ab9mPFqZQ09ElE8Sp8x7G7ZG OK+9hGOr7ecY0vP6FMesB6DK87j6LKbJQWkBHAuwFJfEB3go9wK2wzWtQgB2Im+mkdSI IT+A== MIME-Version: 1.0 X-Received: by 10.180.189.17 with SMTP id ge17mr20471607wic.17.1365519494124; Tue, 09 Apr 2013 07:58:14 -0700 (PDT) Received: by 10.216.194.196 with HTTP; Tue, 9 Apr 2013 07:58:14 -0700 (PDT) X-Originating-IP: [209.66.78.50] In-Reply-To: <5FD2125C-678B-4DCB-B9ED-33C0D3AB2B81@longcount.org> References: <5163F4D4.1090505@rdtc.ru> <5FD2125C-678B-4DCB-B9ED-33C0D3AB2B81@longcount.org> Date: Tue, 9 Apr 2013 10:58:14 -0400 Message-ID: Subject: Re: Release ISO images have broken RockRidge data From: Mark Saad To: FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnH+tZakOOcO0VirYullMnGkbjLzT65Ebn8sHJhl941nkg/4REBOmeSqpWGfETC0rXXOZ1c 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, 09 Apr 2013 14:58:21 -0000 On Tue, Apr 9, 2013 at 9:21 AM, Mark Saad wrote: > > > On Apr 9, 2013, at 7:00 AM, Eugene Grosbein wrote: > >> Hi! >> >> Release ISO images located at ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ISO-IMAGES/ >> were generated with mkisofs until switch to makefs. For example, >> ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ISO-IMAGES/8.2/FreeBSD-8.2-RELEASE-amd64-livefs.iso >> was generated with mkisofs and has correct RockRidge extended attributes. >> >> # isoinfo -d -R -i FreeBSD-8.2-RELEASE-amd64-livefs.iso >> System id: FreeBSD >> Volume id: FreeBSD_LiveFS >> Volume set id: >> Publisher id: The FreeBSD Project. http://www.freebsd.org/ >> Data preparer id: >> Application id: MKISOFS ISO 9660/HFS FILESYSTEM BUILDER & CDRECORD CD-R/DVD CREATOR (C) 1993 E.YOUNGDALE (C) 1997 J.PEARSON/J.SCHILLING >> Copyright File id: >> Abstract File id: >> Bibliographic File id: >> Rock Ridge signatures version 1 found >> Rock Ridge id 'RRIP_1991A' >> Eltorito validation header: >> Hid 1 >> Bootid 88 (bootable) >> >> This image may be unrolled correctly with respect to hardlinks using xorriso command from ports: >> >> # xorriso -for_backup -load volid \* -indev ../FreeBSD-8.2-RELEASE-amd64-livefs.iso -osirrox on -- -extract / livefs -rollback_end >> >> Newer images (8.3 and later) were generated using makefs that seem to produce incorrect RockRidge data: >> >> # isoinfo -d -R -i FreeBSD-8.4-BETA1-amd64-livefs.iso | grep id >> System id: NetBSD >> Volume id: FREEBSD_LIVEFS >> Volume set id: >> Publisher id: >> Data preparer id: >> Application id: >> Copyright File id: >> Abstract File id: >> Bibliographic File id: >> Rock Ridge signatures version 1 found >> Rock Ridge id 'IEEE_P1282' >> Eltorito validation header: >> Hid 1 >> Bootid 88 (bootable) >> >> Same xorriso command produces tons of following error messages and unrolls the image >> without respect to hardlinkg increasing size in nearly 3 times: >> >> libisofs: WARNING : Invalid TF entry >> Caused by: Wrong or damaged RR entry >> >> bsdtar from 8.3-STABLE shows lots of errors too, while extracting FreeBSD-8.4-BETA1-amd64-livefs.iso >> mdconfig breaks hardlinks too. >> >> Is it possible to unroll this image respecting hardlinks? >> >> Eugene Grosbein >> > > While not the same you can always do this > > mdconfig -a -t vnode -f yourfreebsd-version.iso > > mount -t cd9660 /dev/md0 /cdrom > > Then use pax, cpio , cp, rsync etc to copy the data off the image . > > Also if memory serves me right libarchive may be able to unpack an iso much like a tar or cpio archive . Double check that . > > Also makefs was imported from netbsd I would see if netbsd's isos have the same issues . > > Hope this helps > --- > Mark saad | mark.saad@longcount.org > So I did some testing and NetBSD's isos, which are generated much the same way as FreeBSD's , have the same issue . # xorriso -for_backup -load volid \* -indev ../NetBSD-6.1_RC2-amd64.iso -osirrox on -- -extract / netbsd -rollback_en ....... libisofs: NOTE : > Caused by: Wrong or damaged RR entry libisofs: WARNING : Invalid TF entry libisofs: NOTE : > Caused by: Wrong or damaged RR entry libisofs: WARNING : Invalid TF entry libisofs: NOTE : > Caused by: Wrong or damaged RR entry xorriso : UPDATE : 2004 nodes read in 1 seconds libisofs: WARNING : Found hidden El-Torito image. Its size could not be figure out, so image modify or boot image patching may lead to bad results. xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded Drive current: -indev '../NetBSD-6.1_RC2-amd64.iso' Media current: stdio file, overwriteable Media status : is written , is appendable Boot record : El Torito Media summary: 1 session, 169279 data blocks, 331m data, 194g free Volume id : 'NETBSD_61_RC2' Copying of file objects from ISO image to disk filesystem is: Enabled xorriso : UPDATE : 16 files restored ( 97911k) in 1 seconds , 63.7xD xorriso : UPDATE : 22 files restored ( 173.5m) in 2 seconds , 52.2xD xorriso : UPDATE : 30 files restored ( 252.6m) in 3 seconds , 53.3xD xorriso : UPDATE : 458 files restored ( 297.2m) in 4 seconds , 33.8xD xorriso : UPDATE : 1486 files restored ( 328.4m) in 5 seconds = 50.0xD Extracted from ISO image: file '/'='/opt/home/XXXX/Storage/extract/netbsd' Also for what its worth, tar does work at extracting an iso as well # tar -zxvf ../FreeBSD-7.4-RELEASE-i386-disc1.iso -C out x . x 7.4-RELEASE x 7.4-RELEASE/base x 7.4-RELEASE/catpages x 7.4-RELEASE/manpages x 7.4-RELEASE/games x 7.4-RELEASE/proflibs x 7.4-RELEASE/dict x 7.4-RELEASE/info x 7.4-RELEASE/doc x 7.4-RELEASE/kernels x 7.4-RELEASE/ports x 7.4-RELEASE/src x floppies x boot x boot/zfs x boot/firmware x boot/kernel x boot/modules x boot/defaults x packages x packages/All x packages/converters x packages/devel x packages/gnome x packages/emulators x packages/linux ...... So , what issues does this cause ? Have your filed a pr with FreeBSD or NetBSD ? -- mark saad | nonesuch@longcount.org From owner-freebsd-stable@FreeBSD.ORG Tue Apr 9 15:13: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 AC0AD791 for ; Tue, 9 Apr 2013 15:13:08 +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 45D78ED for ; Tue, 9 Apr 2013 15:13:07 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate1.intern.punkt.de with ESMTP id r39FD6Pg046537 for ; Tue, 9 Apr 2013 17:13:06 +0200 (CEST) Received: from hausen-mbp.intern.punkt.de (hausen-mbp.intern.punkt.de [217.29.45.127] (may be forged)) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id r39FD6ud045727 for ; Tue, 9 Apr 2013 17:13:06 +0200 (CEST) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: svn - but smaller? From: "Patrick M. Hausen" In-Reply-To: <4B4FBDA2-A871-430F-AB9C-6027C2B9A354@punkt.de> Date: Tue, 9 Apr 2013 17:13:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <72B0A49E-B6A3-4767-A28A-F3E3E284B738@punkt.de> References: <513E2DA5.70200@mac.com> <20130313152150.E32142@sola.nimnet.asn.au> <20130315111849.GF79102@e-Gitt.NET> <4B4FBDA2-A871-430F-AB9C-6027C2B9A354@punkt.de> To: "freebsd-stable@freebsd.org List" X-Mailer: Apple Mail (2.1503) 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, 09 Apr 2013 15:13:08 -0000 Hi, Am 09.04.2013 um 17:05 schrieb Patrick M. Hausen : > PORTSSUPFILE=3D -b base/head -l /usr/ports ports/head, of course. Regards Patrick M. Hausen Leiter Netzwerke und Sicherheit --=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 Tue Apr 9 15:15:27 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 ED2528CB for ; Tue, 9 Apr 2013 15:15:27 +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 88515118 for ; Tue, 9 Apr 2013 15:15:27 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate1.intern.punkt.de with ESMTP id r39F5Sds046433 for ; Tue, 9 Apr 2013 17:05:28 +0200 (CEST) Received: from hausen-mbp.intern.punkt.de (hausen-mbp.intern.punkt.de [217.29.45.127] (may be forged)) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id r39F5SGR045539 for ; Tue, 9 Apr 2013 17:05:28 +0200 (CEST) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: svn - but smaller? From: "Patrick M. Hausen" In-Reply-To: <20130315111849.GF79102@e-Gitt.NET> Date: Tue, 9 Apr 2013 17:05:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4B4FBDA2-A871-430F-AB9C-6027C2B9A354@punkt.de> References: <513E2DA5.70200@mac.com> <20130313152150.E32142@sola.nimnet.asn.au> <20130315111849.GF79102@e-Gitt.NET> To: "freebsd-stable@freebsd.org List" X-Mailer: Apple Mail (2.1503) 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, 09 Apr 2013 15:15:28 -0000 Hi, all, first a big big thank you to John an all others involved for all the = work. A bit more slowly than cvsup but definitely a lot more convenient than using plain subversion. Part of the slow performance may be due to the fact that there is no local German svn mirror, yet. I'll try with my own = mirror in a couple of days. I immediately asked myself: how can I set this up so I can use "make = update" like I'm used to? SVN_UPDATE looks for a .svn directory, so it cannot = work with svnup. Here's how: root@gordon:/ # cat /etc/make.conf=20 SUP_UPDATE=3D yes SUP=3D /usr/local/bin/svnup SUPHOST=3D svn0.us-east.freebsd.org SUPFLAGS=3D SUPFILE=3D -b base/stable/9 -l /usr/src PORTSSUPFILE=3D -b base/head -l /usr/ports OK, this gives a big warning banner and it's an abuse of a mechanism = intended for another utility =85 but it works nonetheless ;-) I therefore propose an extension to /usr/src/Makefile.inc1 like this: update: .if defined(SVNUP_UPDATE) @echo = "--------------------------------------------------------------" @echo ">>> Running ${SVNUP}" @echo = "--------------------------------------------------------------" .if defined(SVNUPFLAGS) @${SVNUP} ${SVNUPFLAGS} -h ${SVNUPHOST} .endif =85 Just a rough sketch - I can put more thought into this if nobody else is = already working on it. Best regards, Patrick M. Hausen Leiter Netzwerke und Sicherheit --=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 Tue Apr 9 18:56:23 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 8CC3F498 for ; Tue, 9 Apr 2013 18:56:23 +0000 (UTC) (envelope-from scdbackup@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by mx1.freebsd.org (Postfix) with ESMTP id 0FE562E4 for ; Tue, 9 Apr 2013 18:56:22 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LcmGP-1UprjG34i7-00kBii for ; Tue, 09 Apr 2013 20:56:21 +0200 Received: (qmail invoked by alias); 09 Apr 2013 18:56:21 -0000 Received: from 165.126.46.212.adsl.ncore.de [212.46.126.165] by mail.gmx.net (mp012) with SMTP; 09 Apr 2013 20:56:21 +0200 X-Authenticated: #2145628 X-Provags-ID: V01U2FsdGVkX18uuuhQ+IMuauAsU0irBHECgAEqyyPF0gSUMc7THK n7BJwB7TnPCoko Date: Tue, 09 Apr 2013 20:56:07 +0200 From: "Thomas Schmitt" To: freebsd-stable@freebsd.org Subject: Re: Release ISO images have broken RockRidge data Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <26033633425787870041@scdbackup.webframe.org> 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: Tue, 09 Apr 2013 18:56:23 -0000 Hi, thanks for flying xorriso. :)) I am its developer and came to this thread by googling, not by being subscribed here. Sorry for not having a message-id by which i could attach this mail to the thread. -------------------------------------------------------------------- >>> libisofs: WARNING : Invalid TF entry The image FreeBSD-8.4-BETA1-amd64-livefs.iso indeed has a Rock Ridge flaw: The TF entries announce in their FLAGS byte by value 0x07 that there are three timestamps. Each is supposed to have 7 bytes. 5 bytes of entry header and 21 bytes of timestamps would sum up to 26. But the length in LEN_TF is 0x19 = 25. The next entry "NM" begins where the last byte of the last timestamp should be: 00014370 : 00 00 00 00 54 46 19 01 07 71 03 14 05 00 1d 00 T F q 00014380 : 71 03 14 03 0d 10 00 71 03 14 04 3b 1a 4e 4d 09 q q ; N M The missing byte would tell the time zone of POSIX atime. (I should curb the number of error messages.) -------------------------------------------------------------------- >>> Is it possible to unroll this image respecting hardlinks? Theoretically yes. But xorriso will not do yet. The problem sits in the PX entries: Although the ER Extension Identifier is "IEEE_P1282" and thus indicates RRIP 1.12, the size of PX entries is 0x24 = 36 as with RRIP 1.10 rather than 44 as prescribed by RRIP 1.12. The missing bytes would host a 32 bit File Serial Number (inode number) (as usual with ISO 9660 recorded in both byte sexes). The PX entries of mkisofs have 44 bytes (although ER announces RRIP 1.10 by "RRIP_1991A") and thus have inode numbers. xorriso does restore hardlinks if enabled and if the PX entries contain File Serial Numbers. xorriso could try to deduce hardlink relations from the data content addresses. Same address and non-zero length would indicate hardlink relation between two file names. (Zero length files are often mapped to the same content address without being hardlinks.) -------------------------------------------------------------------- Related specs: SUSP 1.12 (entries CE , PD , SP , ST , ER , ES) ftp://ftp.ymi.com/pub/rockridge/susp112.ps RRIP 1.12 (entries PX , PN , SL , NM , CL , PL , RE , TF , SF) ftp://ftp.ymi.com/pub/rockridge/rrip112.ps ECMA-119 aka ISO 9660 http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf -------------------------------------------------------------------- If FreeBSD is looking for a ISO 9660 + Rock Ridge generator: xorriso does this too. Bootable via El Torito, MBR, GPT, APM. I once tested https://wiki.freebsd.org/AvgLiveCD with xorriso -as mkisofs ...proposed.options... -------------------------------------------------------------------- Have a nice day :) Thomas From owner-freebsd-stable@FreeBSD.ORG Tue Apr 9 19:38: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 5E8176B for ; Tue, 9 Apr 2013 19:38:12 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:48]) by mx1.freebsd.org (Postfix) with ESMTP id 452C2808 for ; Tue, 9 Apr 2013 19:38:12 +0000 (UTC) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta05.emeryville.ca.mail.comcast.net with comcast id MvRT1l0020QkzPwA5veBHC; Tue, 09 Apr 2013 19:38:11 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta02.emeryville.ca.mail.comcast.net with comcast id MveA1l00W1t3BNj8NveA2d; Tue, 09 Apr 2013 19:38:11 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 79E5B73A39; Tue, 9 Apr 2013 12:38:10 -0700 (PDT) Date: Tue, 9 Apr 2013 12:38:10 -0700 From: Jeremy Chadwick To: Christian Baer Subject: Re: -Os breaks buildworld Message-ID: <20130409193810.GA10964@icarus.home.lan> References: <3845278.lKnuOXNTV5@lianli4> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3845278.lKnuOXNTV5@lianli4> 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=1365536291; bh=ksN16ycHBnAf/WLIeVCwAc+lBcOJDpT/F1Z2tpBTBqk=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=CEzKMtAP616WJWZG7WIKK4lNhZVxmx6UdPOgWlgP7nj6tcEhzC7JHGzzHE6JHjAUV LXnQq30h/ZNW54Mk9j/FOWzgzxZgBWCGDauycf1cUZ4Qv84Bw+xFD1td7s7VMPsEZ5 Ft6BK0BgcpH5blbA5L3d39ZfkcGGL0gWQK77WRO9IaHxc34Y3TK8BNVbPw38Sn7Puy KsT3CRCNxccvSutIcXdEUocd84TT8XzTBo029UabTQwKvVsmoS8nuu8Z6TbnAphT6H KMPOBTYFEz9adlN/iFt/XThlC3ug1+le8SeXIuZwEQoIdRJM5p9DIxZ2yqY6n5m4EA h6fMgZQKjy1cQ== 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, 09 Apr 2013 19:38:12 -0000 On Tue, Apr 09, 2013 at 02:50:29PM +0200, Christian Baer wrote: > Hey everyone! > > This is not really an important issue, I just wanted to find out if anyone had > it on his or her radar. > > I have a machine that isn't too powerful and hasn't got a lot of RAM either. > So as an experiment I wanted to compile the world with the option for > conserving space. Unfortunately, that didn't work out too well as it broke the > compile (see last lines appended after my signature). > > I updated with svn to version 249301 before compiling. > > The same code compiled with O2 works fine. I know you are going to ask about > my CFLAGS, so here they are: > > CPUTYPE= athlon-xp > CFLAGS= -O2 -fno-strict-aliasing -pipe -mtune=athlon-xp -march=athlon-xp > > And yes, the CPU is really an Athlon XP. ;-) > The only change I need to make to break the compile is -O2 to -Os. > > Has anyone noticed this too? A few things: 1. You didn't state which compiler you're using. 2. Your CFLAGS line above shows -O2, yet your output below shows -Os, and your Subject line is talking about -Os. 3. You should use CPUTYPE?= not CPUTYPE. 4. You need to use CFLAGS+= not CFLAGS=, otherwise you're effectively overriding flags that may be needed/set elsewhere within Makefiles. Furthermore, are you aware of the other internals which -Os disables? -Os disables the following optimization flags: -falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-and-partition -fprefetch-loop-arrays -ftree-vect-loop-version I would suggest not messing with the optimisation level in CFLAGS. This has come up/been discussed on the mailing lists repeatedly for almost two decades. I believe I read somewhere that adjusting that is basically "not supported" nor will it ever be. > famous last lines... :-) > > cc -Os -fno-strict-aliasing -pipe -mtune=athlon-xp -march=athlon-xp > -march=athlon-xp -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include > -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include > -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys > -I/usr/src/lib/libthr/../../libexec/rtld-elf > -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 > -I/usr/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS > -DSYSCALL_COMPAT -std=gnu99 -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign > -c /usr/src/lib/libthr/sys/thr_error.c cc -Os -fno-strict-aliasing -pipe > -mtune=athlon-xp -march=athlon-xp -march=athlon-xp -DPTHREAD_KERNEL > -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread > -I/usr/src/lib/libthr/../../include > -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys > -I/usr/src/lib/libthr/../../libexec/rtld-elf > -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 > -I/usr/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS > -DSYSCALL_COMPAT -std=gnu99 -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign > -c /usr/src/lib/libthr/thread/thr_affinity.c > cc1: warnings being treated as errors > /usr/src/lib/libthr/thread/thr_affinity.c: In function > '_pthread_setaffinity_np': /usr/src/lib/libthr/thread/thr_umtx.h:103: > warning: inlining failed in call to '_thr_umutex_unlock': --param > max-inline-insns-single limit reached > /usr/src/lib/libthr/thread/thr_affinity.c:56: warning: called from here > /usr/src/lib/libthr/thread/thr_umtx.h:103: warning: inlining failed in > call to '_thr_umutex_unlock': --param max-inline-insns-single limit > reached /usr/src/lib/libthr/thread/thr_affinity.c:64: warning: called > from here *** Error code 1 > > Stop in /usr/src/lib/libthr. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 -- | 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 Tue Apr 9 21:11: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 826BD6E3 for ; Tue, 9 Apr 2013 21:11:15 +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 49B23E63 for ; Tue, 9 Apr 2013 21:11:15 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::4d63:2bde:2d40:a6d0] (unknown [IPv6:2001:7b8:3a7:0:4d63:2bde:2d40:a6d0]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 83EDC5C44; Tue, 9 Apr 2013 23:11:14 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: -Os breaks buildworld From: Dimitry Andric In-Reply-To: <3845278.lKnuOXNTV5@lianli4> Date: Tue, 9 Apr 2013 23:11:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3845278.lKnuOXNTV5@lianli4> To: Christian Baer X-Mailer: Apple Mail (2.1503) 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, 09 Apr 2013 21:11:15 -0000 On Apr 9, 2013, at 14:50, Christian Baer = wrote: ... > CPUTYPE=3D athlon-xp > CFLAGS=3D -O2 -fno-strict-aliasing -pipe -mtune=3Dathlon-xp = -march=3Dathlon-xp As mentioned in this thread: - CPUTYPE should be set with ?=3D, not =3D - CFLAGS should be set with +=3D, not =3D - Do not explicitly add -march or -mtune, use CPUTYPE exclusively - If you want -Os optimization, do not put -O2 in CFLAGS ... > cc -Os -fno-strict-aliasing -pipe -mtune=3Dathlon-xp -march=3Dathlon-xp > -march=3Dathlon-xp -DPTHREAD_KERNEL = -I/usr/src/lib/libthr/../libc/include > -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include > -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys > -I/usr/src/lib/libthr/../../libexec/rtld-elf > -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 > -I/usr/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS > -DSYSCALL_COMPAT -std=3Dgnu99 -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized = -Wno-pointer-sign > -c /usr/src/lib/libthr/sys/thr_error.c cc -Os -fno-strict-aliasing = -pipe > -mtune=3Dathlon-xp -march=3Dathlon-xp -march=3Dathlon-xp = -DPTHREAD_KERNEL > -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread=20 > -I/usr/src/lib/libthr/../../include > -I/usr/src/lib/libthr/arch/i386/include -I/usr/src/lib/libthr/sys > -I/usr/src/lib/libthr/../../libexec/rtld-elf > -I/usr/src/lib/libthr/../../libexec/rtld-elf/i386 > -I/usr/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS > -DSYSCALL_COMPAT -std=3Dgnu99 -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized = -Wno-pointer-sign > -c /usr/src/lib/libthr/thread/thr_affinity.c > cc1: warnings being treated as errors > /usr/src/lib/libthr/thread/thr_affinity.c: In function > '_pthread_setaffinity_np': /usr/src/lib/libthr/thread/thr_umtx.h:103: > warning: inlining failed in call to '_thr_umutex_unlock': --param > max-inline-insns-single limit reached > /usr/src/lib/libthr/thread/thr_affinity.c:56: warning: called from = here > /usr/src/lib/libthr/thread/thr_umtx.h:103: warning: inlining failed in > call to '_thr_umutex_unlock': --param max-inline-insns-single limit > reached /usr/src/lib/libthr/thread/thr_affinity.c:64: warning: called > from here *** Error code 1 Try building with NO_WERROR=3D in make.conf or src.conf. In this case, gcc is warning that it cannot inline some function, but that should not matter for the result. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 10 05:30:11 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 E9164E7D for ; Wed, 10 Apr 2013 05:30:11 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 80C66319 for ; Wed, 10 Apr 2013 05:30:10 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r3A5U5D3010678; Wed, 10 Apr 2013 12:30:05 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5164F8D8.8030604@rdtc.ru> Date: Wed, 10 Apr 2013 12:30:00 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Saad Subject: Re: Release ISO images have broken RockRidge data References: <5163F4D4.1090505@rdtc.ru> <5FD2125C-678B-4DCB-B9ED-33C0D3AB2B81@longcount.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: 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: Wed, 10 Apr 2013 05:30:12 -0000 09.04.2013 21:58, Mark Saad ÐÉÛÅÔ: >> While not the same you can always do this >> >> mdconfig -a -t vnode -f yourfreebsd-version.iso >> >> mount -t cd9660 /dev/md0 /cdrom >> >> Then use pax, cpio , cp, rsync etc to copy the data off the image . This way breaks hardlinks, so /rescue expands to 690M instead of 5M. >> Also if memory serves me right libarchive may be able to unpack an iso much like a tar or cpio archive . Double check that . > Also for what its worth, tar does work at extracting an iso as well bsdtar/libarchive fails to expand these images correctly do to its own bugs: # ktrace -i tar xf ../FreeBSD-8.4-BETA1-amd64-livefs.iso usr/bin/make: Can't create 'usr/bin/make' usr/bin/pic: Can't create 'usr/bin/pic' usr/bin/post-grohtml: Can't create 'usr/bin/post-grohtml' usr/include/_semaphore.h: Can't create 'usr/include/_semaphore.h' usr/lib/libarchive.so.5: Can't create 'usr/lib/libarchive.so.5' ^C # kdump | grep -B 12 "'usr/bin/make'" 10247 bsdtar CALL link(0x284eff20,0x284c6180) 10247 bsdtar NAMI "usr/bin/mailq" 10247 bsdtar NAMI "usr/bin/make" 10247 bsdtar RET link -1 errno 18 Cross-device link 10247 bsdtar CALL umask(S_IWGRP|S_IWOTH) 10247 bsdtar RET umask 0 10247 bsdtar CALL write(0x2,0x7fbfe788,0xc) 10247 bsdtar GIO fd 2 wrote 12 bytes "usr/bin/make" 10247 bsdtar RET write 12/0xc 10247 bsdtar CALL write(0x2,0x7fbfe788,0x1d) 10247 bsdtar GIO fd 2 wrote 29 bytes ": Can't create 'usr/bin/make'" > So , what issues does this cause ? Have your filed a pr with FreeBSD or NetBSD ? Not yet. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 10 06:07:46 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 E46A1512 for ; Wed, 10 Apr 2013 06:07:46 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) by mx1.freebsd.org (Postfix) with ESMTP id 9C1DE647 for ; Wed, 10 Apr 2013 06:07:46 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1UPnYc-0001ZD-H5 for stable@freebsd.org; Wed, 10 Apr 2013 12:26:54 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id r3A5RSxE052665 for ; Wed, 10 Apr 2013 12:27:28 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id r3A5RBre052605 for stable@freebsd.org; Wed, 10 Apr 2013 12:27:11 +0700 (NOVT) (envelope-from danfe) Date: Wed, 10 Apr 2013 12:27:10 +0700 From: Alexey Dokuchaev To: stable@freebsd.org Subject: fusefs-kmod does not work on 8-STABLE? Message-ID: <20130410052710.GA36137@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i 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, 10 Apr 2013 06:07:47 -0000 Hey all, I've got puzzled with the fact that fusefs-kmod apparently does not on recent 8-STABLE: it builds and loads, but I don't see normal "fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.19" like I do on 9-STABLE (installed on the same laptop with almost identical kernel config). The result is that /dev/fuse0 never gets created, and any fuse mount attempt results in this message: fuse: failed to open fuse device: No such file or directory Quick googling did not give me any good clues; perhaps someone here on the list knows better how to remedy this problem? Thanks, ./danfe From owner-freebsd-stable@FreeBSD.ORG Wed Apr 10 11:33:20 2013 Return-Path: Delivered-To: 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 D58D5E8A for ; Wed, 10 Apr 2013 11:33:20 +0000 (UTC) (envelope-from feld@feld.me) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by mx1.freebsd.org (Postfix) with ESMTP id AB14689D for ; Wed, 10 Apr 2013 11:33:17 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9562844B; Wed, 10 Apr 2013 07:33:11 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 10 Apr 2013 07:33:11 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=feld.me; h= content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to; s= mesmtp; bh=ECWTuzcMBy0p5BoHu2rJrBYSFvI=; b=qP5jF7Zu9ZrJiKnkdyuUD r5/8EgYY4AexiV8S533BURPImSb18+FneQD6UBPHULAffi21fgH1Y3VHkdH522yO G6zUEMfSa8c4J7SdOI1CgXx/rnjEfZ+x72aBnua5YEFh/p1SLm2M4Ud6WqyI3d01 7XlASQy1UBbDf6JQSWcPh0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:to:subject:references:date :mime-version:content-transfer-encoding:from:message-id :in-reply-to; s=smtpout; bh=ECWTuzcMBy0p5BoHu2rJrBYSFvI=; b=ZOVk KSE25BVGXslaZ35bU8d3m5aTPYbDahqtP5a2KbBaaMgx7lWnuv4I8poUVBgw0IWX E+Q3fWtkewsKqLi3iM+DTEehjCH9LJIjta9K0YHiXYdQb4AuIYYIC1L1ZoviUmyf JS6IhcQatikdSm86+DXqZi/M2Zn0A7PS7LUwKpw= X-Sasl-enc: jw6LfW8Dv9xNPfHU45bhgpr64BSLeZxqABEw7n1EK6PN 1365593591 Received: from tech304.office.supranet.net (unknown [66.170.8.18]) by mail.messagingengine.com (Postfix) with ESMTPA id 3195FC80005; Wed, 10 Apr 2013 07:33:11 -0400 (EDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: stable@freebsd.org, "Alexey Dokuchaev" Subject: Re: fusefs-kmod does not work on 8-STABLE? References: <20130410052710.GA36137@regency.nsu.ru> Date: Wed, 10 Apr 2013 06:33:10 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: <20130410052710.GA36137@regency.nsu.ru> User-Agent: Opera Mail/12.14 (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, 10 Apr 2013 11:33:20 -0000 FUSE is pretty bad outside of FreeBSD 10 where it's rewritten and part of the kernel. If your environment would be OK with making the leap to FreeBSD 10 I'd recommend it. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 10 14:40: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 B2A03E20 for ; Wed, 10 Apr 2013 14:40:01 +0000 (UTC) (envelope-from damonray@mac.hush.com) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by mx1.freebsd.org (Postfix) with ESMTP id 95E2D220 for ; Wed, 10 Apr 2013 14:40:01 +0000 (UTC) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id 5787B1B5242 for ; Wed, 10 Apr 2013 14:09:53 +0000 (UTC) Received: from smtp.hushmail.com (w4.hushmail.com [65.39.178.50]) by smtp10.hushmail.com (Postfix) with ESMTP; Wed, 10 Apr 2013 14:09:53 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 31C3D10E2D3; Wed, 10 Apr 2013 14:09:53 +0000 (UTC) MIME-Version: 1.0 Date: Wed, 10 Apr 2013 09:09:52 -0500 To: "Fabian Wenk" , freebsd-stable@freebsd.org Subject: Re: Ghosted logins in w/who From: damonray@mac.hush.com In-Reply-To: <516428D2.9020701@wenks.ch> References: <20130409015643.0817D10E2C8@smtp.hushmail.com> <20130409022837.GA95155@icarus.home.lan> <516428D2.9020701@wenks.ch> Message-Id: <20130410140953.31C3D10E2D3@smtp.hushmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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, 10 Apr 2013 14:40:01 -0000 If I wipe the utmp file all the w/who content goes away, resets if you will. But in a matter of moments the problem reappears.. is this something that needs to be submitted as a bug report do you think? Thanks! Damon On 4/9/2013 at 9:42 AM, "Fabian Wenk" wrote:Hello Daniel On 09.04.2013 12:07, Daniel Braniss wrote: > something changed beteen 8 and 9 with respect of handling of utmp, > I tried to research this but got bogged down with other things. According to /usr/src/UPDATING: 20100113: The utmp user accounting database has been replaced with utmpx, the user accounting interface standardized by POSIX. Unfortunately the semantics of utmp and utmpx don't match, making it practically impossible to support both interfaces. The user accounting database is used by tools like finger(1), last(1), talk(1), w(1) and ac(8). All applications in the base system use utmpx. This means only local binaries (e.g. from the ports tree) may still use these utmp database files. These applications must be rebuilt to make use of utmpx. After the system has been upgraded, it is safe to remove the old log files (/var/run/utmp, /var/log/lastlog and /var/log/wtmp*), assuming their contents is of no importance anymore. Old wtmp databases can only be used by last(1) and ac(8) after they have been converted to the new format using wtmpcvt(1). Could this have any impact regarding this issue with telnet login? bye Fabian _______________________________________________ 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 Wed Apr 10 14:43: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 B6D42348 for ; Wed, 10 Apr 2013 14:43:33 +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 4986526C for ; Wed, 10 Apr 2013 14:43:33 +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 1UPwF5-0007iA-Tr; Wed, 10 Apr 2013 16:43:20 +0200 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 1UPwF5-0001Ln-1X; Wed, 10 Apr 2013 16:43:19 +0200 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Fabian Wenk" , freebsd-stable@freebsd.org, damonray@mac.hush.com Subject: Re: Ghosted logins in w/who References: <20130409015643.0817D10E2C8@smtp.hushmail.com> <20130409022837.GA95155@icarus.home.lan> <516428D2.9020701@wenks.ch> <20130410140953.31C3D10E2D3@smtp.hushmail.com> Date: Wed, 10 Apr 2013 16:43:17 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <20130410140953.31C3D10E2D3@smtp.hushmail.com> User-Agent: Opera Mail/12.15 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.5 X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05 autolearn=disabled version=3.3.1 X-Scan-Signature: 74bd734068bee68206891dc8710ce62a 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, 10 Apr 2013 14:43:33 -0000 On Wed, 10 Apr 2013 16:09:52 +0200, wrote: > If I wipe the utmp file all the w/who content goes away, resets if you > will. But in a matter of moments the problem reappears.. is this > something that needs to be submitted as a bug report do you think? > Thanks! > Damon Did you upgrade correctly? Did you also ran make delete-old and make delete-old-libs? And did you rebuild all ports after that? Some things might use the old stuff still. Ronald. > > On 4/9/2013 at 9:42 AM, "Fabian Wenk" wrote:Hello Daniel > > On 09.04.2013 12:07, Daniel Braniss wrote: >> something changed beteen 8 and 9 with respect of handling of utmp, >> I tried to research this but got bogged down with other things. > > According to /usr/src/UPDATING: > > 20100113: > The utmp user accounting database has been replaced with utmpx, > the user accounting interface standardized by POSIX. > Unfortunately the semantics of utmp and utmpx don't match, > making it practically impossible to support both interfaces. > The user accounting database is used by tools like finger(1), > last(1), talk(1), w(1) and ac(8). > > All applications in the base system use utmpx. This means only > local binaries (e.g. from the ports tree) may still use these > utmp database files. These applications must be rebuilt to make > use of utmpx. > > After the system has been upgraded, it is safe to remove the old > log files (/var/run/utmp, /var/log/lastlog and /var/log/wtmp*), > assuming their contents is of no importance anymore. Old wtmp > databases can only be used by last(1) and ac(8) after they have > been converted to the new format using wtmpcvt(1). > Could this have any impact regarding this issue with telnet login? > bye > Fabian > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Apr 10 14:48: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 D787B4E8 for ; Wed, 10 Apr 2013 14:48:55 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by mx1.freebsd.org (Postfix) with ESMTP id 644532B1 for ; Wed, 10 Apr 2013 14:48:55 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id t1so614983lbd.10 for ; Wed, 10 Apr 2013 07:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=eTLHP7lMotmaMHU8ikEhW/7iWisObROmZ++ilL9Uutc=; b=sB5QJJFIfg+rFYil1O2AlBdxNaMEvKBsSrw+Wkucky3OBipqlMZ6B7cXMKaz8AKhzL LRlPQdxFfPQcDnNSgeS25Oneo0BwxGSK2j0OI2BeBIVCoz+aUwlcoJggHwUfeMU8Jf4k z0sImQJkSloF6JKzHL973ik5UQQnV5OWghPosBdyPWWh7ICTSsWMpYgEG5kPdgiBQJf6 VQKvdzIqYRiHQgTxYajEkFuuqPHDVkFWsXquYORCd7Lb+S8KjDW4vo+O/s5vZGiOf+aB UUjn/0B2/YZKI8fRFzv8MFvPm/Mzr1PNoMHfOSC2kYTXF4VXlD0eXlgpTwCtxSkD7C8u wAfA== MIME-Version: 1.0 X-Received: by 10.152.6.10 with SMTP id w10mr1204236law.30.1365605333920; Wed, 10 Apr 2013 07:48:53 -0700 (PDT) Received: by 10.112.198.201 with HTTP; Wed, 10 Apr 2013 07:48:53 -0700 (PDT) In-Reply-To: <20130410140953.31C3D10E2D3@smtp.hushmail.com> References: <20130409015643.0817D10E2C8@smtp.hushmail.com> <20130409022837.GA95155@icarus.home.lan> <516428D2.9020701@wenks.ch> <20130410140953.31C3D10E2D3@smtp.hushmail.com> Date: Wed, 10 Apr 2013 15:48:53 +0100 Message-ID: Subject: Re: Ghosted logins in w/who From: Tom Evans To: damonray@mac.hush.com Content-Type: text/plain; charset=UTF-8 Cc: Fabian Wenk , 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, 10 Apr 2013 14:48:55 -0000 On Wed, Apr 10, 2013 at 3:09 PM, wrote: > If I wipe the utmp file all the w/who content goes away, resets if you > will. But in a matter of moments the problem reappears.. is this > something that needs to be submitted as a bug report do you think? > Thanks! > Damon > Hi Damon Fabian was explaining to you that utmp was replaced by utmpx. All programs in base that wrote to utmp now write to utmpx instead. If you still have programs not from base that write to utmp, you will get incorrect/crazy values reported - you must rebuild all tools that currently write to utmp so that they no longer do so. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Wed Apr 10 14:59: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 A468F7AC for ; Wed, 10 Apr 2013 14:59:41 +0000 (UTC) (envelope-from damonray@mac.hush.com) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by mx1.freebsd.org (Postfix) with ESMTP id 85CAD328 for ; Wed, 10 Apr 2013 14:59:41 +0000 (UTC) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id E31D8319DB for ; Wed, 10 Apr 2013 14:59:34 +0000 (UTC) Received: from smtp.hushmail.com (w4.hushmail.com [65.39.178.50]) by smtp1.hushmail.com (Postfix) with ESMTP; Wed, 10 Apr 2013 14:59:34 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 72F4C10E2D3; Wed, 10 Apr 2013 14:59:34 +0000 (UTC) MIME-Version: 1.0 Date: Wed, 10 Apr 2013 09:59:34 -0500 To: "Tom Evans" Subject: Re: Ghosted logins in w/who From: damonray@mac.hush.com In-Reply-To: References: <20130409015643.0817D10E2C8@smtp.hushmail.com> <20130409022837.GA95155@icarus.home.lan> <516428D2.9020701@wenks.ch> <20130410140953.31C3D10E2D3@smtp.hushmail.com> Message-Id: <20130410145934.72F4C10E2D3@smtp.hushmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Fabian Wenk , 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, 10 Apr 2013 14:59:41 -0000 Got it. I'll double check to make sure everything was recompiled correctly. Thanks! Damon On 4/10/2013 at 9:49 AM, "Tom Evans" wrote:On Wed, Apr 10, 2013 at 3:09 PM, wrote: > If I wipe the utmp file all the w/who content goes away, resets if you > will. But in a matter of moments the problem reappears.. is this > something that needs to be submitted as a bug report do you think? > Thanks! > Damon > Hi Damon Fabian was explaining to you that utmp was replaced by utmpx. All programs in base that wrote to utmp now write to utmpx instead. If you still have programs not from base that write to utmp, you will get incorrect/crazy values reported - you must rebuild all tools that currently write to utmp so that they no longer do so. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Wed Apr 10 17:28:00 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 EC07D728 for ; Wed, 10 Apr 2013 17:28:00 +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 AFFD7C23 for ; Wed, 10 Apr 2013 17:28:00 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r3AHRsiw036831; Wed, 10 Apr 2013 11:27:54 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r3AHRrL5036828; Wed, 10 Apr 2013 11:27:53 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Wed, 10 Apr 2013 11:27:53 -0600 (MDT) From: Warren Block To: Eugene Grosbein Subject: Re: Release ISO images have broken RockRidge data In-Reply-To: <5164F8D8.8030604@rdtc.ru> Message-ID: References: <5163F4D4.1090505@rdtc.ru> <5FD2125C-678B-4DCB-B9ED-33C0D3AB2B81@longcount.org> <5164F8D8.8030604@rdtc.ru> 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.4.3 (wonkity.com [127.0.0.1]); Wed, 10 Apr 2013 11:27:54 -0600 (MDT) Cc: Mark Saad , 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: Wed, 10 Apr 2013 17:28:01 -0000 On Wed, 10 Apr 2013, Eugene Grosbein wrote: > 09.04.2013 21:58, Mark Saad ?????: > >>> While not the same you can always do this >>> >>> mdconfig -a -t vnode -f yourfreebsd-version.iso >>> >>> mount -t cd9660 /dev/md0 /cdrom >>> >>> Then use pax, cpio , cp, rsync etc to copy the data off the image . > > This way breaks hardlinks, so /rescue expands to 690M instead of 5M. rsync will support hard links with -H. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 10 18:29:40 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 AE06CEBF for ; Wed, 10 Apr 2013 18:29:40 +0000 (UTC) (envelope-from scdbackup@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by mx1.freebsd.org (Postfix) with ESMTP id 4A1C8AF for ; Wed, 10 Apr 2013 18:29:39 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.16]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lnmgj-1V4pZN3Mp5-00hu4M for ; Wed, 10 Apr 2013 20:29:38 +0200 Received: (qmail invoked by alias); 10 Apr 2013 18:29:38 -0000 Received: from 165.126.46.212.adsl.ncore.de [212.46.126.165] by mail.gmx.net (mp016) with SMTP; 10 Apr 2013 20:29:38 +0200 X-Authenticated: #2145628 X-Provags-ID: V01U2FsdGVkX18iS2ILGYIim1KHiAY3hHcDyYHVKBi2daX3qeRgB3 wBiRBjSnhiz9nx Date: Wed, 10 Apr 2013 20:29:24 +0200 From: "Thomas Schmitt" To: freebsd-stable@freebsd.org Subject: Re: Release ISO images have broken RockRidge data Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <4267633373880852212@scdbackup.webframe.org> 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: Wed, 10 Apr 2013 18:29:40 -0000 Hi, Warren Block wrote: > sync will support hard links with -H But how shall rsync know that the files in the ISO image stem from hardlink siblings on the hard disk where the image was produced ? -------------------------------------------------------------------- I succeeded with this post-processing on a Linux system with bash after xorriso -for backup ... -extract / livefs : Learn the block address of content of /rescue/cat in the ISO image: lba=$(xorriso -indev ../FreeBSD-8.4-BETA1-amd64-livefs.iso \ -find /rescue/cat -exec report_lba -- 2>/dev/null | \ fgrep cat | \ awk '{print $6}') (Should yield 35682 with that image) Get a list of all files with that block address, except /rescue/cat : siblings=$(xorriso -indev ../FreeBSD-8.4-BETA1-amd64-livefs.iso \ -find / -sort_lba -lba_range "$lba" 1 \ -exec report_lba -- \ 2>/dev/null | \ grep '^File data lba' | awk '{print $12}' | \ sed -e "s/'//g" | grep -v '^/rescue/cat$' ) (This should yield 137 files: /rescue/[ ... /rescue/zpool ) Delete them in livefs/ and re-create them as links to livefs/rescue/cat: for i in $siblings do rm livefs$i ln livefs/rescue/cat livefs$i done This brings the size of livefs/rescue from 676772 KiB to 4924 KiB. ls -l livefs/rescue reports: total 676768 -r-xr-xr-x 138 thomas thomas 5007184 2013-03-20 04:14 [ -r-xr-xr-x 138 thomas thomas 5007184 2013-03-20 04:14 atacontrol ... -r-xr-xr-x 138 thomas thomas 5007184 2013-03-20 04:14 zpool -------------------------------------------------------------------- (Confessedly one could get the file list as well by ls -l and grepping for the size of livefs/rescue/cat.) -------------------------------------------------------------------- Have a nice day :) Thomas From owner-freebsd-stable@FreeBSD.ORG Wed Apr 10 19:51: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 C5AFB389 for ; Wed, 10 Apr 2013 19:51:26 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from smtp.getmail.no (smtp.getmail.no [84.208.15.66]) by mx1.freebsd.org (Postfix) with ESMTP id 84EC967B for ; Wed, 10 Apr 2013 19:51:26 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from get-mta-scan04.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 <0ML100JSJZ1JBG00@get-mta-out01.get.basefarm.net> for freebsd-stable@freebsd.org; Wed, 10 Apr 2013 20:51:19 +0200 (MEST) Received: from get-mta-scan04.get.basefarm.net (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 267811F054CD_165B4A7B for ; Wed, 10 Apr 2013 18:51:19 +0000 (GMT) Received: from kg-v2.kg4.no (cm-84.215.180.206.getinternet.no [84.215.180.206]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by get-mta-scan04.get.basefarm.net (Sophos Email Appliance) with ESMTPSA id 7C7FD1F054CA_165B4A6F for ; Wed, 10 Apr 2013 18:51:18 +0000 (GMT) Date: Wed, 10 Apr 2013 20:51:18 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Subject: Re: fusefs-kmod does not work on 8-STABLE? Message-id: <20130410205118.72ade1f6495310e84226551b@getmail.no> In-reply-to: References: <20130410052710.GA36137@regency.nsu.ru> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.17; amd64-portbld-freebsd8.3) 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, 10 Apr 2013 19:51:26 -0000 On Wed, 10 Apr 2013 06:33:10 -0500 Mark Felder wrote: > FUSE is pretty bad outside of FreeBSD 10 where it's rewritten and part of > the kernel. If your environment would be OK with making the leap to > FreeBSD 10 I'd recommend it. Ate there any bugreports or known problems? Except for one machine (see this thread[1]), it works fine (good enough) for me on a number of FreeBSD machines, and have done so for some years now. I haven't tested fusefs much under FreeBSD 9.0 and newer, I mostly use it with FreeBSD 8.x. I'm only using sshfs and gphotofs. References: 1) http://forums.freebsd.org/showthread.php?t=37302 -- Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Wed Apr 10 22:46:43 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 452AA163; Wed, 10 Apr 2013 22:46:43 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id CBE00F27; Wed, 10 Apr 2013 22:46:42 +0000 (UTC) Received: from glenbarber.us (unknown [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 2D2E723F804; Wed, 10 Apr 2013 18:46:40 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.2 onyx.glenbarber.us 2D2E723F804 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Wed, 10 Apr 2013 18:46:38 -0400 From: Glen Barber To: freebsd-stable@FreeBSD.org Subject: FreeBSD 8.4-RC1 Now Available Message-ID: <20130410224638.GA1539@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Release Engineering Team 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, 10 Apr 2013 22:46:43 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The first RC build of the 8.4-RELEASE release cycle is now available on the FTP servers for the amd64, i386, and pc98 architectures. The SHA256/MD5 sums are tacked on to the bottom of this message. The ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/8.4/ (or any of the FreeBSD mirror sites). If you notice problems you can report them through the normal Gnats PR system or here on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system use "releng/8.4". If you would like to use csup/cvsup mechanisms instead the branch tag to use is "RELENG_8_4". Please be aware that cvsup and CVS are both deprecated, and while upgrades using CVS or cvsup may work now they will not be supported for security updates through the life of 8.4. Important notice when upgrading from 8.4-BETA1 to 8.4-RC1: - There was an accidental breakage in the OpenSSL ABI in the BETA1 build that was fixed before this RC build. Applications built against OpenSSL may need to be rebuilt after upgrading to 8.4-RC1 from 8.4-BETA1. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 8.4-RC1 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 7.x. Alternatively, the user can install misc/compat7x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install Checksums: SHA256 (FreeBSD-8.4-RC1-amd64-bootonly.iso) = a5f1bce4c5aefeef12353da6f637275310df6315417a1c9b6022da4106ea4c4c SHA256 (FreeBSD-8.4-RC1-amd64-disc1.iso) = 9adf9e15ff288085a53831ad238cd7320225f186dfb3faac11ba2189689f4678 SHA256 (FreeBSD-8.4-RC1-amd64-disc2.iso) = faad5199011bd23302b2b8916b7a0abbd0f755e15bdb90a289972e7dfc3c752a SHA256 (FreeBSD-8.4-RC1-amd64-disc3.iso) = 9c907f4d74f28965a8a6ce683a946f9aeaba37dbbd97ca63f7fc3f28b839d9bd SHA256 (FreeBSD-8.4-RC1-amd64-dvd1.iso) = 6f6c706ea1cb6f045d0df596bf85873784e3b42bb22ae3fe26d54deb4115f63e SHA256 (FreeBSD-8.4-RC1-amd64-livefs.iso) = 1110f7ced80df95fb8354bac2614c866dcc608fc9c1c1b823d832d3cb93ce16a SHA256 (FreeBSD-8.4-RC1-amd64-memstick.img) = 10f3b891df47345c800d1210a1881baf473114aaea9a44d4ce0f86e5ba09221f SHA256 (FreeBSD-8.4-RC1-i386-bootonly.iso) = 116b34780cf6c684fb6ac541630d2e863613bd66447f894b77ce682ba2bedb38 SHA256 (FreeBSD-8.4-RC1-i386-disc1.iso) = ba1d20cc407d392e61469ec4b5c49b68187317a651165bf8693d690eaf1c8539 SHA256 (FreeBSD-8.4-RC1-i386-disc2.iso) = 1b35d1b3430910a6c558f36d4417bc8a5cc030f3233f2f1a27f9732971f71aed SHA256 (FreeBSD-8.4-RC1-i386-disc3.iso) = a948ee4707450f55b416fc42972629dafe84d22ec14ecf5f89772f07e44e0d31 SHA256 (FreeBSD-8.4-RC1-i386-dvd1.iso) = 32bc73f2881baf4cde80d04c830604643dfc1dd33ec6cfccd72cbe40cb7f8584 SHA256 (FreeBSD-8.4-RC1-i386-livefs.iso) = e9e280849935605f595380ce0455720332598c6ab4a2a57cee38c13cb3d0e8a6 SHA256 (FreeBSD-8.4-RC1-i386-memstick.img) = 5aed82b6679a92448096287128075e636f6cd34f338e93a39ee8610fa995fb83 SHA256 (FreeBSD-8.4-RC1-pc98-bootonly.iso) = 7ad9faea2fb1276b42c104b608a6fac6d0a5b83a56b952eab9c7c6165ffd819f SHA256 (FreeBSD-8.4-RC1-pc98-disc1.iso) = 191ec9361e64b205354de0a7522f4302dc35bb8e167e393df886040b5a14476b SHA256 (FreeBSD-8.4-RC1-pc98-livefs.iso) = f38592cd6b4336a3e6444335dc6e9cc1ac173063481878c82105e4af487259f6 MD5 (FreeBSD-8.4-RC1-amd64-bootonly.iso) = 5f39ee60f64e11d1e1098272926a7c40 MD5 (FreeBSD-8.4-RC1-amd64-disc1.iso) = cdc885b419049ce2a324e3c491c53c0c MD5 (FreeBSD-8.4-RC1-amd64-disc2.iso) = f82e6b3067c16888636558c7070c4a0d MD5 (FreeBSD-8.4-RC1-amd64-disc3.iso) = e3d031665ee0f7bd3108921fab665cd4 MD5 (FreeBSD-8.4-RC1-amd64-dvd1.iso) = a721eba1bb0ff6b415c96f063b6f50f6 MD5 (FreeBSD-8.4-RC1-amd64-livefs.iso) = 2bab297001dce4b5d8b75cc9adf0bc49 MD5 (FreeBSD-8.4-RC1-amd64-memstick.img) = 32d73c87cd326ba33d1710d1d80924a6 MD5 (FreeBSD-8.4-RC1-i386-bootonly.iso) = 985a7dcfa7e7832c4b078c28140889f0 MD5 (FreeBSD-8.4-RC1-i386-disc1.iso) = 20bcbd7b4c842e23c4b40b7d95cb7189 MD5 (FreeBSD-8.4-RC1-i386-disc2.iso) = 99cdd663e248f7153f83ef2efca78126 MD5 (FreeBSD-8.4-RC1-i386-disc3.iso) = 0fdc4e0d4becafed7becea7e283dc956 MD5 (FreeBSD-8.4-RC1-i386-dvd1.iso) = 9452ea665417bf8e3b37e6a2df9e0471 MD5 (FreeBSD-8.4-RC1-i386-livefs.iso) = 3958875d5849efb7d354b5ad00cfa974 MD5 (FreeBSD-8.4-RC1-i386-memstick.img) = 295086f72d72f10d1212a09bcb36f6f0 MD5 (FreeBSD-8.4-RC1-pc98-bootonly.iso) = 2ea56e5a085ba73c9caae9ddc739d915 MD5 (FreeBSD-8.4-RC1-pc98-disc1.iso) = 31ecd8bcfbb97ea38b7833ba4fe9d41e MD5 (FreeBSD-8.4-RC1-pc98-livefs.iso) = 6699df5f2691976843d273ef000a861e Glen --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRZevOAAoJEFJPDDeguUajINAH/iD++JUsWMDEoysvmNJx9irY Uwq5ufCOdO1hTKjfmikmo5xNuFce2/yIqDSNFlUabWRQNUoUdlMp1wWJm0Vk7PVP hfxqZxJcONu5X9Xs/QaRrowq5QGLTBlxe0AfBr7QJjS17RBu/RU02vDtWMwRnvq0 Lh5B8h1JnOWiMc6RoRsmawwgxfczkhwFtdVChb8yVxZeYEE9YG6Us+GiQPbfeqAs heUJpspTqoarjQh1x/LNCCNf/ilDoti4xKCltjpW2++dIyJRqUntIyNi0utXptR3 DYNyB26VbH3I5rM+seNpuPMto/ZEkjLGAkfs0kpk+Eg2ThzI6sxnC5T25FpvMJs= =F0df -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 10 23:44: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 10B37FE4 for ; Wed, 10 Apr 2013 23:44:36 +0000 (UTC) (envelope-from cforgeron@acsi.ca) Received: from AA-Edge2007.acsi.ca (unknown [IPv6:2001:0:4137:9e76:16:37b1:e721:f5ad]) by mx1.freebsd.org (Postfix) with ESMTP id C1A5F1EA for ; Wed, 10 Apr 2013 23:44:35 +0000 (UTC) Received: from AA-EX0.acsi.ca (192.168.9.11) by AA-Edge2007.acsi.ca (192.168.9.15) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 10 Apr 2013 16:39:33 -0300 Received: from AA-EX0.acsi.ca ([::1]) by AA-EX0.acsi.ca ([::1]) with mapi id 14.02.0298.004; Wed, 10 Apr 2013 16:39:33 -0300 From: Chris Forgeron To: "freebsd-stable@freebsd.org" Subject: kern/165903: mbuf leak Thread-Topic: kern/165903: mbuf leak Thread-Index: Ac4biy6IuBBGvQzdTV+HyC/2Nu0hHw== Date: Wed, 10 Apr 2013 19:39:31 +0000 Message-ID: <46D80686C389884BB0C047851038EC456D8BCEBC@AA-EX0.acsi.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.9.108] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.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: Wed, 10 Apr 2013 23:44:36 -0000 Hello, I've updated the PR on this via bug track email (hopefully, it bounced my = first email) , but I thought I should bring it to the attention of the list= as it's still happening, and the original PR was from March 2012. The PR is here: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D165903&cat=3D I am experiencing the same mbuf leak on fresh 9.1-RELEASE machines (AMD64)= . Most of my machines are ESXi 5.1 VM's running the e1000 (em0) NIC. This V= M is stock, just one freebsd-update done, nothing custom. I have also experienced this condition on an older 9.0-STABLE from Jul 1st= 2012. I did not notice it much before that date, but I can't tell for sure= . I have a few machines on that build that I still use, so confirmation was= easy. I do not experience the error if I load up vmware tools and use the vmx3f0= adapter, it's just with em0. I have set the mbufs to very high numbers (322144) to buy more time betwee= n lockups/crashes. Most often the systems stay functional, they just need a= reboot or more mbufs if I add them. Some times they lock up or crash as I = ifconfig down/up the adapter or attempt to add more mbufs via sysctl. 1) Is anyone else able to reproduce this problem? The PR is still open, wh= ich says to me not all of us can be having this problem or there would be m= ore drive to fix. 2) What do I need to help with to advance this problem? It's not just my s= ystems, as evidenced by the original poster of the PR. Thanks. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 10 23:53: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 CE3FA216 for ; Wed, 10 Apr 2013 23:53:49 +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 B3A06241 for ; Wed, 10 Apr 2013 23:53:49 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta12.emeryville.ca.mail.comcast.net with comcast id NN1F1l00517UAYkACPtooi; Wed, 10 Apr 2013 23:53:48 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta13.emeryville.ca.mail.comcast.net with comcast id NPtn1l00x1t3BNj8ZPtoyv; Wed, 10 Apr 2013 23:53:48 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A4D0673A33; Wed, 10 Apr 2013 16:53:47 -0700 (PDT) Date: Wed, 10 Apr 2013 16:53:47 -0700 From: Jeremy Chadwick To: Chris Forgeron Subject: Re: kern/165903: mbuf leak Message-ID: <20130410235347.GA38492@icarus.home.lan> References: <46D80686C389884BB0C047851038EC456D8BCEBC@AA-EX0.acsi.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46D80686C389884BB0C047851038EC456D8BCEBC@AA-EX0.acsi.ca> 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=1365638028; bh=w9lPOjeeQAbGaBAWpOlJetS2TWhsfC8MfRxXGRhSEmQ=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=ChS0/Z092GOV5o5Hn/L2IXiybLqH9WBeAxA/DtdMqSrE0NoJt8NcCNKnpROk6+KD5 7hyTVuTPGjlUc5+8z27fLtMkM1aEwpng5bJKAx6xDp+mu3nj5rbCn9C3JuHm0iB2ev CM3gCi2rLhnd2ttwaAV8FZLCgfYn4FsA1AahwuP9Bkkw0zD69nw2qP+SVLHJOQhD/N 91XOGJ/XIsSuOCE+QSa0x8MX3w0LEP3LPtJvj9KMe1K9/QWPskqH9LstFi/vjspSt6 IvutE6bu7tnPzYSH5fa2s0nTO5slTaoqIbzGQrhm9YzPZ45n6x61ERXEpwEDpY9a07 Z3aytGtCCrdtw== 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, 10 Apr 2013 23:53:49 -0000 On Wed, Apr 10, 2013 at 07:39:31PM +0000, Chris Forgeron wrote: > I've updated the PR on this via bug track email (hopefully, it bounced my first email) , but I thought I should bring it to the attention of the list as it's still happening, and the original PR was from March 2012. > > The PR is here: http://www.freebsd.org/cgi/query-pr.cgi?pr=165903&cat= > > I am experiencing the same mbuf leak on fresh 9.1-RELEASE machines (AMD64). Most of my machines are ESXi 5.1 VM's running the e1000 (em0) NIC. This VM is stock, just one freebsd-update done, nothing custom. > > I have also experienced this condition on an older 9.0-STABLE from Jul 1st 2012. I did not notice it much before that date, but I can't tell for sure. I have a few machines on that build that I still use, so confirmation was easy. > > I do not experience the error if I load up vmware tools and use the vmx3f0 adapter, it's just with em0. > > I have set the mbufs to very high numbers (322144) to buy more time between lockups/crashes. Most often the systems stay functional, they just need a reboot or more mbufs if I add them. Some times they lock up or crash as I ifconfig down/up the adapter or attempt to add more mbufs via sysctl. > > 1) Is anyone else able to reproduce this problem? The PR is still open, which says to me not all of us can be having this problem or there would be more drive to fix. > 2) What do I need to help with to advance this problem? It's not just my systems, as evidenced by the original poster of the PR. 1. This PR does not contain output from "dmesg" nor "pciconf -lvbc", nor does your Email. Output from this matters. 2. Please try 9.1-STABLE and see if there is an improvement; there have been a huge number of changes/fixes to em(4) between 9.1-RELEASE and now. You can try this: https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/9.1-RELENG_9-r249290-JPSNAP/ -- | 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 Apr 11 00:08: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 9DEE84EC for ; Thu, 11 Apr 2013 00:08:19 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:17]) by mx1.freebsd.org (Postfix) with ESMTP id 83AA32BA for ; Thu, 11 Apr 2013 00:08:19 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta10.emeryville.ca.mail.comcast.net with comcast id NQ4W1l0070lTkoCAAQ8KJl; Thu, 11 Apr 2013 00:08:19 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta04.emeryville.ca.mail.comcast.net with comcast id NQ8J1l00G1t3BNj8QQ8Jh5; Thu, 11 Apr 2013 00:08:19 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8777D73A33; Wed, 10 Apr 2013 17:08:18 -0700 (PDT) Date: Wed, 10 Apr 2013 17:08:18 -0700 From: Jeremy Chadwick To: Chris Forgeron Subject: Re: kern/165903: mbuf leak Message-ID: <20130411000818.GA38803@icarus.home.lan> References: <46D80686C389884BB0C047851038EC456D8BCEBC@AA-EX0.acsi.ca> <20130410235347.GA38492@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130410235347.GA38492@icarus.home.lan> 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=1365638899; bh=dD/cKkrr0vWaOVfcYuwTBWWwsQYTDuEC2z/4cCTDnIM=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=lFZ71dzeWCjbDQsb1EkaSoN3J/hzIrojtk26eIMUdyaSXxbC9e4mEyI0UkhPT91Uc NfHnIIZIAlyrCzQ53uhttLapUW1SuibOsbCHIcMN+rQl0Rn7Ug1k6kYrsdI71yUZUq PpDC6IsRkvKG5+vlxjPov7K8Owm4zjfoDyzbGleb4Oh2zyxX/zQDVDPzLx48QnI+Ng qpyzqa6p3Fr2DXHiUPf7WKZkb/6008Qi/c3TZ2eidLsiPiHfz89eY8HHPqjlfV+y4z 0enDfeVwuRrnZCs5sTiHwyIrV44avykYgoG6bMsWbFpmVM/n98YMvejxSpU7hoDwpM 1+rg+83IUYLuA== 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, 11 Apr 2013 00:08:19 -0000 On Wed, Apr 10, 2013 at 04:53:47PM -0700, Jeremy Chadwick wrote: > On Wed, Apr 10, 2013 at 07:39:31PM +0000, Chris Forgeron wrote: > > I've updated the PR on this via bug track email (hopefully, it bounced my first email) , but I thought I should bring it to the attention of the list as it's still happening, and the original PR was from March 2012. > > > > The PR is here: http://www.freebsd.org/cgi/query-pr.cgi?pr=165903&cat= > > > > I am experiencing the same mbuf leak on fresh 9.1-RELEASE machines (AMD64). Most of my machines are ESXi 5.1 VM's running the e1000 (em0) NIC. This VM is stock, just one freebsd-update done, nothing custom. > > > > I have also experienced this condition on an older 9.0-STABLE from Jul 1st 2012. I did not notice it much before that date, but I can't tell for sure. I have a few machines on that build that I still use, so confirmation was easy. > > > > I do not experience the error if I load up vmware tools and use the vmx3f0 adapter, it's just with em0. > > > > I have set the mbufs to very high numbers (322144) to buy more time between lockups/crashes. Most often the systems stay functional, they just need a reboot or more mbufs if I add them. Some times they lock up or crash as I ifconfig down/up the adapter or attempt to add more mbufs via sysctl. > > > > 1) Is anyone else able to reproduce this problem? The PR is still open, which says to me not all of us can be having this problem or there would be more drive to fix. > > 2) What do I need to help with to advance this problem? It's not just my systems, as evidenced by the original poster of the PR. > > 1. This PR does not contain output from "dmesg" nor "pciconf -lvbc", nor > does your Email. Output from this matters. > > 2. Please try 9.1-STABLE and see if there is an improvement; there have > been a huge number of changes/fixes to em(4) between 9.1-RELEASE and > now. You can try this: > > https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/9.1-RELENG_9-r249290-JPSNAP/ Other output that would be useful on a machine where the current mbuf count is actively very high: * vmstat -z * netstat -Q * netstat -n -x It would also be beneficial to provide any sysctl.conf and loader.conf adjustments you do. -- | 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 Apr 11 01: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 DE3B0257 for ; Thu, 11 Apr 2013 01:47:12 +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 92CFE7F6 for ; Thu, 11 Apr 2013 01:47:12 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r3B1lBSH077046; Wed, 10 Apr 2013 19:47:11 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r3B1lA7R077043; Wed, 10 Apr 2013 19:47:11 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Wed, 10 Apr 2013 19:47:10 -0600 (MDT) From: Warren Block To: Thomas Schmitt Subject: Re: Release ISO images have broken RockRidge data In-Reply-To: <4267633373880852212@scdbackup.webframe.org> Message-ID: References: <4267633373880852212@scdbackup.webframe.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 10 Apr 2013 19:47:11 -0600 (MDT) 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, 11 Apr 2013 01:47:12 -0000 On Wed, 10 Apr 2013, Thomas Schmitt wrote: > Hi, > > Warren Block wrote: >> sync will support hard links with -H > > But how shall rsync know that the files in the ISO image stem from > hardlink siblings on the hard disk where the image was produced ? Well, no it won't recreate them by inferral. Although that would be kind of a neat option for rsync, which can already deal with checksums. But when copying files, it does support hard links. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 11 01:58: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 5BA1188A for ; Thu, 11 Apr 2013 01:58:50 +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 18D2F88D for ; Thu, 11 Apr 2013 01:58:49 +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 12706967 for freebsd-stable@freebsd.org; Wed, 10 Apr 2013 20:58:43 -0500 From: "John Mehr" Subject: Re: svn - but smaller? To: "freebsd-stable@freebsd.org List" X-Mailer: CommuniGate Pro WebUser v5.3.11 Date: Wed, 10 Apr 2013 20:58:43 -0500 Message-ID: In-Reply-To: <4B4FBDA2-A871-430F-AB9C-6027C2B9A354@punkt.de> References: <513E2DA5.70200@mac.com> <20130313152150.E32142@sola.nimnet.asn.au> <20130315111849.GF79102@e-Gitt.NET> <4B4FBDA2-A871-430F-AB9C-6027C2B9A354@punkt.de> MIME-Version: 1.0 Content-Type: text/plain;charset=windows-1252; 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, 11 Apr 2013 01:58:50 -0000 On Tue, 9 Apr 2013 17:05:28 +0200  "Patrick M. Hausen" wrote: > Hi, all, > > first a big big thank you to John an all others involved >for all the work. > > A bit more slowly than cvsup but definitely a lot more >convenient than > using plain subversion. Part of the slow performance may >be due to the > fact that there is no local German svn mirror, yet. I'll >try with my own mirror > in a couple of days. > > I immediately asked myself: how can I set this up so I >can use "make update" > like I'm used to? SVN_UPDATE looks for a .svn directory, >so it cannot work with > svnup. > > Here's how: > > root@gordon:/ # cat /etc/make.conf > SUP_UPDATE= yes > SUP= /usr/local/bin/svnup > SUPHOST= svn0.us-east.freebsd.org > SUPFLAGS= > SUPFILE= -b base/stable/9 -l /usr/src > PORTSSUPFILE= -b base/head -l /usr/ports > > OK, this gives a big warning banner and it's an abuse of >a mechanism intended > for another utility … but it works nonetheless ;-) > > I therefore propose an extension to >/usr/src/Makefile.inc1 like this: > > update: > .if defined(SVNUP_UPDATE) >        @echo >"--------------------------------------------------------------" >        @echo ">>> Running ${SVNUP}" >        @echo >"--------------------------------------------------------------" > .if defined(SVNUPFLAGS) >        @${SVNUP} ${SVNUPFLAGS} -h ${SVNUPHOST} > .endif > … > > Just a rough sketch - I can put more thought into this >if nobody else is already > working on it. > > Best regards, > Patrick M. Hausen > Leiter Netzwerke und Sicherheit > -- > punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe > Tel. 0721 9109 0 * Fax 0721 9109 100 > info@punkt.de       http://www.punkt.de > Gf: Jürgen Egeling      AG Mannheim 108285 > > > > _______________________________________________ > 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, I've added support for a configuration/preferences file to store commonly used settings for an arbitrary number of branches (ports, stable, current, etc.).  For the default groups, they can easily be synchronized by executing "svnup ports", "svnup stable", etc. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 11 05:44: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 A8BFA549 for ; Thu, 11 Apr 2013 05:44:05 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 5091BDB for ; Thu, 11 Apr 2013 05:44:04 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r3B5hxbI008555; Thu, 11 Apr 2013 12:43:59 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <51664D9A.2080501@rdtc.ru> Date: Thu, 11 Apr 2013 12:43:54 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Warren Block Subject: Re: Release ISO images have broken RockRidge data References: <5163F4D4.1090505@rdtc.ru> <5FD2125C-678B-4DCB-B9ED-33C0D3AB2B81@longcount.org> <5164F8D8.8030604@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: Mark Saad , 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: Thu, 11 Apr 2013 05:44:05 -0000 11.04.2013 00:27, Warren Block ÐÉÛÅÔ: > On Wed, 10 Apr 2013, Eugene Grosbein wrote: > >> 09.04.2013 21:58, Mark Saad ?????: >> >>>> While not the same you can always do this >>>> >>>> mdconfig -a -t vnode -f yourfreebsd-version.iso >>>> >>>> mount -t cd9660 /dev/md0 /cdrom >>>> >>>> Then use pax, cpio , cp, rsync etc to copy the data off the image . >> >> This way breaks hardlinks, so /rescue expands to 690M instead of 5M. > > rsync will support hard links with -H. Rsync won't be able to _detect_ already broken hardlinks. It won't dig inside ISO image for them and mdconfig/mount break them. So, rsync is not an option. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Thu Apr 11 05:58: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 4851797F for ; Thu, 11 Apr 2013 05:58:23 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0179C179 for ; Thu, 11 Apr 2013 05:58:22 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::726]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r3B5wJEb061710 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 11 Apr 2013 11:58:19 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <516650FB.2020504@norma.perm.ru> Date: Thu, 11 Apr 2013 11:58:19 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: kern/165903: mbuf leak References: <46D80686C389884BB0C047851038EC456D8BCEBC@AA-EX0.acsi.ca> In-Reply-To: <46D80686C389884BB0C047851038EC456D8BCEBC@AA-EX0.acsi.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Thu, 11 Apr 2013 11:58:19 +0600 (YEKT) X-Spam-Status: No hits=-97.8 bayes=0.5 testhits RDNS_NONE=1.274, SPF_SOFTFAIL=0.972,USER_IN_WHITELIST=-100 autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru 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, 11 Apr 2013 05:58:23 -0000 Hi. On 11.04.2013 01:39, Chris Forgeron wrote: > I do not experience the error if I load up vmware tools and use the vmx3f0 adapter, it's just with em0. > > I have set the mbufs to very high numbers (322144) to buy more time between lockups/crashes. Most often the systems stay functional, they just need a reboot or more mbufs if I add them. Some times they lock up or crash as I ifconfig down/up the adapter or attempt to add more mbufs via sysctl. > > 1) Is anyone else able to reproduce this problem? The PR is still open, which says to me not all of us can be having this problem or there would be more drive to fix. > 2) What do I need to help with to advance this problem? It's not just my systems, as evidenced by the original poster of the PR. > (I'm the author of the PR). I was experiencing this on 9.0 'till some -STABLE, after that the leak was gone on the exactly same configuration. This server is equipped with bce(4) interfaces only, so I don't see any connection with interface driver. I think it's more configuration related. I created this pr in order to investigate why one of my 9.x servers hangs periodically. Since that I tried lots of 9-STABLE snapshots, none of them fixed my problem. Last month I decided to switch to 10.x. The uptime is 37 days so far, none of my 9.x snapshots was able to stand that long. Even if this machine will crash while I write this - this definitely means that 10.x right now is at least equally stable as 9.x is, and can run as smoothly as 9.x does. My advice - use 10.0-CURRENT, 9.0 and all of it's descendant versions are broken beyond repair, imo. Switching to 10.x was a hard decision for me too, I was too scared by the '-CURRENT' karma. Seems like it's not that creepy. Eugene. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 11 07:15: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 BF4008F6 for ; Thu, 11 Apr 2013 07:15:04 +0000 (UTC) (envelope-from mrboco@gmail.com) Received: from mail-vc0-f192.google.com (mail-vc0-f192.google.com [209.85.220.192]) by mx1.freebsd.org (Postfix) with ESMTP id 893A862A for ; Thu, 11 Apr 2013 07:15:04 +0000 (UTC) Received: by mail-vc0-f192.google.com with SMTP id gd11so373294vcb.19 for ; Thu, 11 Apr 2013 00:14:57 -0700 (PDT) X-Received: by 10.49.95.231 with SMTP id dn7mr474946qeb.39.1365664497807; Thu, 11 Apr 2013 00:14:57 -0700 (PDT) Path: glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: fa.freebsd.stable Date: Thu, 11 Apr 2013 00:14:57 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=81.30.199.254; posting-account=sMcwMQoAAAAdu1V-A3R0KelfgYVS8M25 NNTP-Posting-Host: 81.30.199.254 References: User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-IP: 81.30.199.254 MIME-Version: 1.0 Message-ID: <88b872cf-7795-4d69-91c7-6c3107299b33@googlegroups.com> Subject: Re: svn - but smaller? From: mrboco@gmail.com To: fa.freebsd.stable@googlegroups.com 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: Thu, 11 Apr 2013 07:15:04 -0000 On Sunday, March 24, 2013 9:57:12 AM UTC+6, Markiyan Kushnir wrote: > Tested svnup for a while, and I can say it does its job well, and works > basically as I would expect, so thanks for your initiative. Although it > appears to be quite resource greedy. Most of the time it showed > something like: > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 22270 mkushnir 1 102 0 44944K 31804K CPU0 1 6:22 97.56% a.out It's because of typo in the send_command() procedure. I've placed the patched svnup.c (0.56), the diff and two statically linked binaries on http://ftp.ufanet.ru/pub/boco/freebsd/svnup/ No more CPU eating and/or strange lockups (so far). Tested both against local and remote repository. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 11 08:39: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 2A92B27E for ; Thu, 11 Apr 2013 08:39:33 +0000 (UTC) (envelope-from mrboco@gmail.com) Received: from mail-yh0-x23d.google.com (mail-yh0-x23d.google.com [IPv6:2607:f8b0:4002:c01::23d]) by mx1.freebsd.org (Postfix) with ESMTP id ED32DA9E for ; Thu, 11 Apr 2013 08:39:32 +0000 (UTC) Received: by mail-yh0-f61.google.com with SMTP id q22so400060yhf.16 for ; Thu, 11 Apr 2013 01:39:32 -0700 (PDT) X-Received: by 10.49.85.106 with SMTP id g10mr483508qez.13.1365669572563; Thu, 11 Apr 2013 01:39:32 -0700 (PDT) Path: glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: fa.freebsd.stable Date: Thu, 11 Apr 2013 01:39:32 -0700 (PDT) In-Reply-To: <88b872cf-7795-4d69-91c7-6c3107299b33@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=81.30.199.254; posting-account=sMcwMQoAAAAdu1V-A3R0KelfgYVS8M25 NNTP-Posting-Host: 81.30.199.254 References: <88b872cf-7795-4d69-91c7-6c3107299b33@googlegroups.com> User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-IP: 81.30.199.254 MIME-Version: 1.0 Message-ID: <0025e959-80c1-417f-9ed5-aeff3c00b05a@googlegroups.com> Subject: Re: svn - but smaller? From: mrboco@gmail.com To: fa.freebsd.stable@googlegroups.com 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: Thu, 11 Apr 2013 08:39:33 -0000 On Thursday, April 11, 2013 1:14:57 PM UTC+6, mrb...@gmail.com wrote: > I've placed the patched svnup.c (0.56), the diff and two statically linked binaries on http://ftp.ufanet.ru/pub/boco/freebsd/svnup/ I'm sorry, svnup.c.diff is the patch against filtered thru indent svnup.c, with different formatting (see README). The patch against the original svnup.c v0.56 is named svnup.c.diff-original. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 11 09:18: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 AC46BFBB for ; Thu, 11 Apr 2013 09:18:26 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0B563D30 for ; Thu, 11 Apr 2013 09:18:25 +0000 (UTC) Received: (qmail 59076 invoked from network); 11 Apr 2013 10:25:33 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Apr 2013 10:25:33 -0000 Message-ID: <51667FDC.7050807@freebsd.org> Date: Thu, 11 Apr 2013 11:18:20 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: EuroBSDcon 2013: Call for Proposals, Conference on September 28+29 2013 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: Thu, 11 Apr 2013 09:18:26 -0000 Excuse me for being slightly spammy but I've received feedback that we haven't spread this information widely enough outside the inner circles and interested people missed the announcement. EuroBSDcon 2013: September 28-29 in Malta ========================================= EuroBSDcon is the European technical conference for users and developers of BSD-based systems. The conference will take place Saturday and Sunday 28-29 September at the Hilton Conference Centre in St. Julian's, Malta (tutorials and FreeBSD Developer Summit on preceding Thursday and Friday, talks on Saturday and Sunday). [Yes, very nice weather at that time of year, about 26/19C sunny no rain, Social event on Saturday evening is going to be a sunset beach BBQ] Call for Proposals ------------------ The EuroBSDcon program committee is inviting BSD developers and users to submit innovative and original talk proposals not previously presented at other European conferences. Topics of interest to the conference include, but are not limited to applications, architecture, implementation, performance and security of BSD-based operating systems, as well as topics concerning the economic or organizational aspects of BSD use. Presentations are expected to be 45 minutes and are to be delivered in English. Call for Tutorial Proposals --------------------------- The EuroBSDcon program committee is also inviting qualified practitioners in their field to submit proposals for half or full day tutorials on topics relevant to development, implementation and use of BSD-based systems. Half-day tutorials are expected to be 2.5 to 3 hours and full-day tutorials 5 to 6 hours. Tutorials are to be held in English. Submissions ----------- Proposals should be sent by email to . They should contain a short and concise text description in about 100 words. The submission should also include a short CV of the speaker and an estimate of the expected travel expenses. Please submit each proposal as a separate email. Important dates --------------- The EuroBSDcon program committee is accepting talk and tutorial proposals until Monday, May 25 2013. Other important dates will be announced soon at the conference website http://2013.EuroBSDcon.org/. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 11 09:19: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 1AA1E256 for ; Thu, 11 Apr 2013 09:19:01 +0000 (UTC) (envelope-from scdbackup@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by mx1.freebsd.org (Postfix) with ESMTP id A5B41D5B for ; Thu, 11 Apr 2013 09:19:00 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MF6cH-1UNgLi0mtf-00GFPB for ; Thu, 11 Apr 2013 11:13:45 +0200 Received: (qmail invoked by alias); 11 Apr 2013 09:13:45 -0000 Received: from 165.126.46.212.adsl.ncore.de [212.46.126.165] by mail.gmx.net (mp017) with SMTP; 11 Apr 2013 11:13:45 +0200 X-Authenticated: #2145628 X-Provags-ID: V01U2FsdGVkX1+8dbE7/Ge84ad3Q4hgSMtYwMkH74fGKx2p4tcoWo G6Cnl+nC4RtNX8 Date: Thu, 11 Apr 2013 11:13:30 +0200 From: "Thomas Schmitt" To: freebsd-stable@freebsd.org Subject: Re: Release ISO images have broken RockRidge data Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <24426633558406658036@scdbackup.webframe.org> 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, 11 Apr 2013 09:19:01 -0000 Hi, i am not sure whether this is the correct source code version of makefs, but here i can see the reason for the bad Rock Ridge TF entries http://svnweb.freebsd.org/base/stable/8/usr.sbin/makefs/cd9660/iso9660_rrip.c?revision=224835&view=markup Line 688 has: p->attr.rr_entry.TF.h.length[0] = 4; This should be 5, because after the 4 bytes of generic SUSP header there is one byte of flags. See typedef of ISO_RRIP_TF in .../iso9660_rrip.h line 135. ------------------------------------------------------------------- The reason for the missing hardlink info can be seen in line 648: /* Ignoring the serial number for now */ The program would have to detect hardlink relations among files which get copied from the local filesystem into the ISO image. It would then have to mark hardlink siblings by giving them the same serial number. This would not show them as hardlinks in mounted images on FreeBSD or Linux. But xorriso would respect them, if -hardlinks is set to "on". (Done by command -for_backup.) ------------------------------------------------------------------- There is a small bug with makefs and the Expiration Time in the Primary Volume Descriptor. http://svnweb.freebsd.org/base/stable/8/usr.sbin/makefs/cd9660.c?revision=225249&view=markup Line 687: memset(diskStructure.primaryDescriptor.expiration_date, '0' ,17); should be something like memset(diskStructure.primaryDescriptor.expiration_date, '0' ,16); ((char *) diskStructure.primaryDescriptor.expiration_date)[16] = 0; ECMA-119 (ISO 9660 for cheapos) 8.4.26.1: "If all characters in RBP 1 to 16 of this field are the digit ZERO and the number in RBP 17 is zero, it shall mean that the date and time are not specified." I just fixed a contrary bug in libisofs. {:) ------------------------------------------------------------------- A year ago FreeBSD 8 had problems with large files in mounted ISO 9660 images and with mounting multi-session images: http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038549.html http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038552.html http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038563.html http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038566.html http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038570.html I wonder whether these have been fixed meanwhile. ------------------------------------------------------------------- Have a nice day :) Thomas From owner-freebsd-stable@FreeBSD.ORG Thu Apr 11 13:04:07 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 5018D235 for ; Thu, 11 Apr 2013 13:04:07 +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 8877DA23 for ; Thu, 11 Apr 2013 13:04:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r3BD3vlk008943; Thu, 11 Apr 2013 23:03:57 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 11 Apr 2013 23:03:57 +1000 (EST) From: Ian Smith To: mrboco@gmail.com Subject: Re: svn - but smaller? In-Reply-To: <88b872cf-7795-4d69-91c7-6c3107299b33@googlegroups.com> Message-ID: <20130411225319.M56386@sola.nimnet.asn.au> References: <88b872cf-7795-4d69-91c7-6c3107299b33@googlegroups.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org, John Mehr 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, 11 Apr 2013 13:04:07 -0000 On Thu, 11 Apr 2013, mrboco@gmail.com wrote: > On Sunday, March 24, 2013 9:57:12 AM UTC+6, Markiyan Kushnir wrote: > > Tested svnup for a while, and I can say it does its job well, and works > > basically as I would expect, so thanks for your initiative. Although it > > appears to be quite resource greedy. Most of the time it showed > > something like: > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 22270 mkushnir 1 102 0 44944K 31804K CPU0 1 6:22 97.56% a.out > > It's because of typo in the send_command() procedure. > > I've placed the patched svnup.c (0.56), the diff and two statically > linked binaries on http://ftp.ufanet.ru/pub/boco/freebsd/svnup/ > > No more CPU eating and/or strange lockups (so far). Tested both > against local and remote repository. I'm sorry, but even ignoring all of your whitespace and style(9) differences, your patch appears to go well beyond correcting a typo, which I can't spot anyway, though I'm sure John will know what it is. Care to explain a little more? Also, what advantage, in this particular case, is there in statically linking? Here it turns a 21.5K i386 binary into one of 575K. If this makes it into base, as I hope it may, that seems a little excessive? cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Thu Apr 11 15:13: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 7DC5DA35 for ; Thu, 11 Apr 2013 15:13:22 +0000 (UTC) (envelope-from mrboco@gmail.com) Received: from mail-qa0-f60.google.com (mail-qa0-f60.google.com [209.85.216.60]) by mx1.freebsd.org (Postfix) with ESMTP id 47A77DF for ; Thu, 11 Apr 2013 15:13:22 +0000 (UTC) Received: by mail-qa0-f60.google.com with SMTP id i13so202705qae.15 for ; Thu, 11 Apr 2013 08:13:21 -0700 (PDT) X-Received: by 10.49.85.165 with SMTP id i5mr635223qez.28.1365693201486; Thu, 11 Apr 2013 08:13:21 -0700 (PDT) Path: glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: fa.freebsd.stable Date: Thu, 11 Apr 2013 08:13:21 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=81.30.199.254; posting-account=sMcwMQoAAAAdu1V-A3R0KelfgYVS8M25 NNTP-Posting-Host: 81.30.199.254 References: User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-IP: 81.30.199.254 MIME-Version: 1.0 Message-ID: Subject: Re: svn - but smaller? From: mrboco@gmail.com To: fa.freebsd.stable@googlegroups.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: John Mehr , freebsd-stable@freebsd.org, mrboco@gmail.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, 11 Apr 2013 15:13:22 -0000 > I'm sorry, but even ignoring all of your whitespace and style(9)=20 > differences, your patch appears to go well beyond correcting a typo,=20 > which I can't spot anyway, though I'm sure John will know what it is. >=20 > Care to explain a little more? Sure. Typo is "strlen(command - total_bytes_written)" instead of "strlen(co= mmand) - total_bytes_written". But then I've noticed that John have used non-blocking IO (useless in our c= ase) while not handling IO errors, that lead us to permanent cycling on EAG= AIN. So I've replaced John's code with the simpler one that blocks on write= () and removed fcntl(..., O_NONBLOCK). Then I've run a lot of tests again my own repository located on the same ma= chine and sometime svnup was locked permanently with send/recieve queues fi= lled up (remote fetching was OK). I've digged a bit in svn code and deceide= d that it would be helpful to use SO_KEEPALIVE and to set SNDBUF (at least)= to the COMMAND_BUFFER value. > Also, what advantage, in this particular case, is there in statically=20 > linking? Here it turns a 21.5K i386 binary into one of 575K. If this=20 > makes it into base, as I hope it may, that seems a little excessive? There is no advantage. I've compiled both binaries for myself to be able to= "svnup" hundreds of mahines w/o wondering about exact release =3D) From owner-freebsd-stable@FreeBSD.ORG Thu Apr 11 17:42:43 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 4D31E979 for ; Thu, 11 Apr 2013 17:42:43 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id D6E9DE2A for ; Thu, 11 Apr 2013 17:42:42 +0000 (UTC) Received: by mail-ea0-f174.google.com with SMTP id m14so853537eaj.5 for ; Thu, 11 Apr 2013 10:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1UGGUlX/9WuhMpXIsZDgEiMKByg4TzPgmgFjz/QyhYI=; b=mOYkYZlbF6gjLF6INxk3DfIWrgDFEXmRFMuB6VM1W3+5ddP2V8d5HcgfL0J6RaeKvv erczkDKsSzpYw/gezQF4mYorYobZGSi4wO5800wpjhywObIp9uJg3dyfzYMz7mSk/aET /XTg/vacMDx9QjMbdEm+sHakdiQ5zGb321UTJWUg06+yumWkKE4D4QQpxlwqrIA0kQ2u UJkw4d02qJFuL06fAUlW9RLMXXc52CD6UfVB0jg5UUeEzSXUNxHZcaTjkFwb6Z6xSVn8 vGbnWifSCQCGjZ+7ngmuoPqeTu/v6FA8oAy/uEOikewko7tnrrj0G/N1hkQ3FxT3apG/ Ufng== X-Received: by 10.14.107.69 with SMTP id n45mr19001306eeg.23.1365702161802; Thu, 11 Apr 2013 10:42:41 -0700 (PDT) Received: from mkushnir.zapto.org (162-69-132-95.pool.ukrtel.net. [95.132.69.162]) by mx.google.com with ESMTPS id i53sm6817911eeu.5.2013.04.11.10.42.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Apr 2013 10:42:41 -0700 (PDT) Message-ID: <5166F605.4080602@gmail.com> Date: Thu, 11 Apr 2013 20:42:29 +0300 From: Markiyan Kushnir User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121119 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? References: <88b872cf-7795-4d69-91c7-6c3107299b33@googlegroups.com> <20130411225319.M56386@sola.nimnet.asn.au> In-Reply-To: <20130411225319.M56386@sola.nimnet.asn.au> 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: Thu, 11 Apr 2013 17:42:43 -0000 I agree with Ian, there is no need to statically link to base libraries. While not going into details of the patch, I can confirm no issues, except of known ones, of course: ports/177777, ports/177408. Another thing that might be worth of attention, the patched version has been again back to slower checkout time: real 91m38.824s user 0m26.216s sys 0m13.858s at 4 Mbit/s link, while the original 0.56 takes ~55min given the same load/network conditions. -- Markiyan On 11.04.2013 16:03, Ian Smith wrote: > On Thu, 11 Apr 2013, mrboco@gmail.com wrote: > > On Sunday, March 24, 2013 9:57:12 AM UTC+6, Markiyan Kushnir wrote: > > > Tested svnup for a while, and I can say it does its job well, and works > > > basically as I would expect, so thanks for your initiative. Although it > > > appears to be quite resource greedy. Most of the time it showed > > > something like: > > > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > > 22270 mkushnir 1 102 0 44944K 31804K CPU0 1 6:22 97.56% a.out > > > > It's because of typo in the send_command() procedure. > > > > I've placed the patched svnup.c (0.56), the diff and two statically > > linked binaries on http://ftp.ufanet.ru/pub/boco/freebsd/svnup/ > > > > No more CPU eating and/or strange lockups (so far). Tested both > > against local and remote repository. > > I'm sorry, but even ignoring all of your whitespace and style(9) > differences, your patch appears to go well beyond correcting a typo, > which I can't spot anyway, though I'm sure John will know what it is. > > Care to explain a little more? > > Also, what advantage, in this particular case, is there in statically > linking? Here it turns a 21.5K i386 binary into one of 575K. If this > makes it into base, as I hope it may, that seems a little excessive? > > cheers, 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 Thu Apr 11 17:53: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 E0CF3DCD for ; Thu, 11 Apr 2013 17:53:15 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id B61D6EBA for ; Thu, 11 Apr 2013 17:53:15 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c10so2407468ieb.3 for ; Thu, 11 Apr 2013 10:53:15 -0700 (PDT) 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=ECJe2b/KmMSKKRnFQ5RfNFTbaCrCZyfNSvpQqMOcJbM=; b=Km9BH5k1G/HLCeQgWcyE4P6ntDp1Wv/xyN6WxweSFgB22DwHHmmn4StwW/WtnJQ+D6 +vwkzLoVjeisMRLkDjJcZ37EQUP36iQVMKftcA/x5InOi9c3c6Xfa3vpa7odzr32pSMC VBC40IKGuuI1kEDF12v7leYQhvTpY3WuahDSK/D6RhloJ/cYuHuV6ZbmoZos/GDbWgUq 6IdnWcfYCO8+u+iuERvZ41IoC5UQACUhRc8gxwbDxew4QKssbrQbGye+pG6drsKvoURP LoAWmYfyU6htWxB/QDGwG5Hk96FwjBb+V4OdSglskLlOskv1iwY9BuiBTL1LZ/Yn/Y90 doKA== X-Received: by 10.50.197.170 with SMTP id iv10mr16561804igc.62.1365702795451; Thu, 11 Apr 2013 10:53:15 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.64.58.52 with HTTP; Thu, 11 Apr 2013 10:52:45 -0700 (PDT) In-Reply-To: <20130410145934.72F4C10E2D3@smtp.hushmail.com> References: <20130409015643.0817D10E2C8@smtp.hushmail.com> <20130409022837.GA95155@icarus.home.lan> <516428D2.9020701@wenks.ch> <20130410140953.31C3D10E2D3@smtp.hushmail.com> <20130410145934.72F4C10E2D3@smtp.hushmail.com> From: Chris Rees Date: Thu, 11 Apr 2013 18:52:45 +0100 X-Google-Sender-Auth: 25jDU8-n4_IotCHMN7EcFUSHDgY Message-ID: Subject: Re: Ghosted logins in w/who To: damonray@mac.hush.com Content-Type: text/plain; charset=ISO-8859-1 Cc: Tom Evans , Fabian Wenk , 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, 11 Apr 2013 17:53:15 -0000 On 10 April 2013 15:59, wrote: > Got it. I'll double check to make sure everything was recompiled > correctly. Thanks! > Damon While you're at it, I'll echo Ronald's concern-- make sure /usr/include/utmp.h does NOT exist for you. If it does, you must run make delete-old in /usr/src. Chris > On 4/10/2013 at 9:49 AM, "Tom Evans" wrote:On Wed, Apr 10, 2013 at > 3:09 PM, wrote: >> If I wipe the utmp file all the w/who content goes away, resets if > you >> will. But in a matter of moments the problem reappears.. is this >> something that needs to be submitted as a bug report do you think? >> Thanks! >> Damon >> > > Hi Damon > > Fabian was explaining to you that utmp was replaced by utmpx. > > All programs in base that wrote to utmp now write to utmpx instead. If > you still have programs not from base that write to utmp, you will get > incorrect/crazy values reported - you must rebuild all tools that > currently write to utmp so that they no longer do so. > > Cheers > > Tom > _______________________________________________ > 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 Thu Apr 11 19:09: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 2AD9898 for ; Thu, 11 Apr 2013 19:09:35 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by mx1.freebsd.org (Postfix) with ESMTP id B372B1410 for ; Thu, 11 Apr 2013 19:09:34 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id c4so906443eek.10 for ; Thu, 11 Apr 2013 12:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=oOelPH+SjIMxVLugkCDWW8CE0mezjsfG0m9TAZCiAqs=; b=VVPU9kRfFHU9SzBfywYsdlSeJeVoQjWgqlBwZU/whuHsSiBfzZWht5f7zn7RRY1++9 cK7p9ThwHsgcetN18SipYKSok9uK9AixCXP1QeoYwKafEDnXbG5Yx5opLlwhNkEkOENR JGXyc29Y+EpXNvjWKS+NKOh2BX+u4gxWbd7b1NCvvGzlFO9gwMmZI3MsswkMCDAp/Pjg LWyDZWWgkO/06QbX90pse4e5RtgmnBlUapLcShMPYR/uJmafCzi4jbwWICazbwZlnLQw G4RX77ivdKZ1oALKoqJIkxGXE/VZFvMhheZEjzfzqtkvQYsY3zypXx4cTwYxlRAaqtAF 0KAQ== X-Received: by 10.15.83.73 with SMTP id b49mr19666295eez.25.1365707367886; Thu, 11 Apr 2013 12:09:27 -0700 (PDT) Received: from mkushnir.zapto.org (162-69-132-95.pool.ukrtel.net. [95.132.69.162]) by mx.google.com with ESMTPS id u44sm7199286eel.7.2013.04.11.12.09.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Apr 2013 12:09:27 -0700 (PDT) Message-ID: <51670A5F.9000901@gmail.com> Date: Thu, 11 Apr 2013 22:09:19 +0300 From: Markiyan Kushnir User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121119 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? References: <88b872cf-7795-4d69-91c7-6c3107299b33@googlegroups.com> <20130411225319.M56386@sola.nimnet.asn.au> <5166F605.4080602@gmail.com> In-Reply-To: <5166F605.4080602@gmail.com> 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: Thu, 11 Apr 2013 19:09:35 -0000 On 11.04.2013 20:42, Markiyan Kushnir wrote: > I agree with Ian, there is no need to statically link to base libraries. > > While not going into details of the patch, I can confirm no issues, > except of known ones, of course: ports/177777, ports/177408. > > Another thing that might be worth of attention, the patched version has > been again back to slower checkout time: > > real 91m38.824s > user 0m26.216s > sys 0m13.858s > > at 4 Mbit/s link, while the original 0.56 takes ~55min given the same > load/network conditions. > So my fresh measurements of the original 0.56 version at 4Mbit/s has shown: real 27m45.944s user 3m43.608s sys 22m35.469s while drawing about 97% of CPU time and 30..50 MB RSS memeory: https://docs.google.com/file/d/0B9Q-zpUXxqCnM1lHVWhNRWF6aUk/edit?usp=sharing Here is how the patched version was doing in roughly equivalent conditions: https://docs.google.com/file/d/0B9Q-zpUXxqCndUhTT2tySV8wdU0/edit?usp=sharing -- Markiyan. > -- > Markiyan > > On 11.04.2013 16:03, Ian Smith wrote: >> On Thu, 11 Apr 2013, mrboco@gmail.com wrote: >> > On Sunday, March 24, 2013 9:57:12 AM UTC+6, Markiyan Kushnir wrote: >> > > Tested svnup for a while, and I can say it does its job well, >> and works >> > > basically as I would expect, so thanks for your initiative. >> Although it >> > > appears to be quite resource greedy. Most of the time it showed >> > > something like: >> > > >> > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME >> WCPU COMMAND >> > > 22270 mkushnir 1 102 0 44944K 31804K CPU0 1 6:22 >> 97.56% a.out >> > >> > It's because of typo in the send_command() procedure. >> > >> > I've placed the patched svnup.c (0.56), the diff and two statically >> > linked binaries on http://ftp.ufanet.ru/pub/boco/freebsd/svnup/ >> > >> > No more CPU eating and/or strange lockups (so far). Tested both >> > against local and remote repository. >> >> I'm sorry, but even ignoring all of your whitespace and style(9) >> differences, your patch appears to go well beyond correcting a typo, >> which I can't spot anyway, though I'm sure John will know what it is. >> >> Care to explain a little more? >> >> Also, what advantage, in this particular case, is there in statically >> linking? Here it turns a 21.5K i386 binary into one of 575K. If this >> makes it into base, as I hope it may, that seems a little excessive? >> >> cheers, 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 Thu Apr 11 20:23:40 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 822AFA22 for ; Thu, 11 Apr 2013 20:23:40 +0000 (UTC) (envelope-from cforgeron@acsi.ca) Received: from AA-Edge2007.acsi.ca (unknown [IPv6:2001:0:4137:9e76:1cf2:338:71bb:44fd]) by mx1.freebsd.org (Postfix) with ESMTP id 407FB1813 for ; Thu, 11 Apr 2013 20:23:40 +0000 (UTC) Received: from AA-EX0.acsi.ca (192.168.9.11) by AA-Edge2007.acsi.ca (192.168.9.15) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 11 Apr 2013 17:23:39 -0300 Received: from AA-EX0.acsi.ca ([::1]) by AA-EX0.acsi.ca ([::1]) with mapi id 14.02.0298.004; Thu, 11 Apr 2013 17:23:39 -0300 From: Chris Forgeron To: Jeremy Chadwick Subject: RE: kern/165903: mbuf leak Thread-Topic: kern/165903: mbuf leak Thread-Index: Ac4biy6IuBBGvQzdTV+HyC/2Nu0hHwa1JruAAACBygAAJAAXIA== Date: Thu, 11 Apr 2013 20:23:37 +0000 Message-ID: <46D80686C389884BB0C047851038EC456D8BE35C@AA-EX0.acsi.ca> References: <46D80686C389884BB0C047851038EC456D8BCEBC@AA-EX0.acsi.ca> <20130410235347.GA38492@icarus.home.lan> <20130411000818.GA38803@icarus.home.lan> In-Reply-To: <20130411000818.GA38803@icarus.home.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.9.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 11 Apr 2013 20:23:40 -0000 I was already starting to load up a fresh 9.1-STABLE box for other testing,= I will also create a stock box (no changes anywhere) and let it idle for a= few days to see if the problem is still there.=20 I'll report back either way in the next few days with results.=20 If I still have problems, I will send the full diags as mentioned below. Thanks.=20 >> 1. This PR does not contain output from "dmesg" nor "pciconf -lvbc",=20 >> nor does your Email. Output from this matters. >>=20 >> 2. Please try 9.1-STABLE and see if there is an improvement; there=20 >> have been a huge number of changes/fixes to em(4) between 9.1-RELEASE=20 >> and now. You can try this: >>=20 >> https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/9.1-RELENG_9-r249 >> 290-JPSNAP/ > >Other output that would be useful on a machine where the current mbuf coun= t is actively very high: > >* vmstat -z >* netstat -Q >* netstat -n -x > >It would also be beneficial to provide any sysctl.conf and loader.conf adj= ustments you do. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 11 22:53: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 91455352 for ; Thu, 11 Apr 2013 22:53:24 +0000 (UTC) (envelope-from karl@denninger.net) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 56BABB8 for ; Thu, 11 Apr 2013 22:53:23 +0000 (UTC) Received: from [192.168.1.40] (localhost [127.0.0.1]) by fs.denninger.net (8.14.6/8.13.1) with ESMTP id r3BMVgDc012253 for ; Thu, 11 Apr 2013 17:31:42 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Thu Apr 11 17:31:42 2013 Message-ID: <516739C9.4080902@denninger.net> Date: Thu, 11 Apr 2013 17:31:37 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: IKEv2/IPSEC "Road Warrior" VPN Tunneling? X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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: Thu, 11 Apr 2013 22:53:24 -0000 Is there a "cookbook" for setting this up? There are examples for setting up a tunnel between two fixed-address networks (e.g. a remote LAN that needs to be "integrated" with a central LAN over IPSec but I can't find anything addressing the other situation -- remote user(s) where the connecting IPs are not known in advance, such as a person with a laptop or smartphone in a random hotel. (And is there a better list for this in the freebsd-* paradigm for the question?) -- -- Karl Denninger /The Market Ticker ®/ Cuda Systems LLC From owner-freebsd-stable@FreeBSD.ORG Fri Apr 12 04:12:02 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 3DDFEB3D for ; Fri, 12 Apr 2013 04:12:02 +0000 (UTC) (envelope-from jxd09@jxdco.com) Received: from smtp.chinaemail.cn (smtp.chinaemail.cn [218.5.74.238]) by mx1.freebsd.org (Postfix) with ESMTP id D1C43E41 for ; Fri, 12 Apr 2013 04:12:01 +0000 (UTC) Received: from s406k.chinaemail.cn (unknown [118.244.204.93]) by smtp.chinaemail.cn (Postfix) with ESMTP id 1493E19066D for ; Fri, 12 Apr 2013 12:11:50 +0800 (CST) Received: from jxd09pc (unknown [27.184.139.11]) (Authenticated sender: jxd09@jxdco.com) by s406k.chinaemail.cn (Bossmail) with ESMTP id 291EB4FA26 for ; Fri, 12 Apr 2013 12:11:45 +0800 (CST) From: "jxd06" To: freebsd-stable@freebsd.org Subject: Re:News Alumina Date: Fri, 12 Apr 2013 12:11:50 +0800 Message-Id: MIME-Version: 1.0 X-Priority: 3 X-Mailer: DreamMail 4.6.9.2 X-MID: 1995754589.608200312.71.1365739905.197967.24489 X-Rate: Yes X-Real-From: jxd09@jxdco.com X-Rcpt: ,freebsd-stable@freebsd.org, X-Mop-Send: ,admin@jxdco.com, Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 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: Fri, 12 Apr 2013 04:12:02 -0000 SGV5IGd1eSwgDQoNCmNvcHBlciB0cmFkaW5nIGhlcmUsIGV4cG9ydGluZyBBbHVtaW5hIG94aWRl IHdpdGggZ29vZCBxdWFsaXR5IGFuZCBsb3cgcHJpY2UgaW4gQ2hpbmEuIA0KDQpDYWxsIG1lLCBs ZXQncyB0YWxrIGRldGFpbHMuIA0KDQpSZ2RzLCANCg0KSmFja3kNCiANCg0KUWluZ2RhbyBKdVhp YW5nRGEgSW1wb3J0JkV4cG9ydCBDTy4sTFREIA0KVEVMOiArODYtNTMyLTgwOTM0Mzc5IEZBWDog Kzg2LTUzMi04MDkzNDM3OSANCk1TTjpKYWNreTIwMTEwODIyQGhvdG1haWwuY29tIA0KVHJhZGVN YW5hZ2VyOiBjbjEwMDE3MDYyNzQgDQpTS1lQRTogSmFja3kyMDExMDgyMg0K From owner-freebsd-stable@FreeBSD.ORG Fri Apr 12 05:43: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 6FB3F585 for ; Fri, 12 Apr 2013 05:43:30 +0000 (UTC) (envelope-from mrboco@gmail.com) Received: from mail-ea0-x23a.google.com (mail-ea0-x23a.google.com [IPv6:2a00:1450:4013:c01::23a]) by mx1.freebsd.org (Postfix) with ESMTP id 09E3F1054 for ; Fri, 12 Apr 2013 05:43:29 +0000 (UTC) Received: by mail-ea0-f186.google.com with SMTP id b15so530712eae.23 for ; Thu, 11 Apr 2013 22:43:29 -0700 (PDT) X-Received: by 10.152.27.170 with SMTP id u10mr103878lag.2.1365745408884; Thu, 11 Apr 2013 22:43:28 -0700 (PDT) Path: glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: fa.freebsd.stable Date: Thu, 11 Apr 2013 22:43:28 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=81.30.199.254; posting-account=sMcwMQoAAAAdu1V-A3R0KelfgYVS8M25 NNTP-Posting-Host: 81.30.199.254 References: User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-IP: 81.30.199.254 MIME-Version: 1.0 Message-ID: Subject: Re: svn - but smaller? From: mrboco@gmail.com To: fa.freebsd.stable@googlegroups.com 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, 12 Apr 2013 05:43:30 -0000 On Friday, April 12, 2013 1:09:53 AM UTC+6, Markiyan Kushnir wrote: > > Another thing that might be worth of attention, the patched version has > > been again back to slower checkout time: > > real 91m38.824s > > user 0m26.216s > > sys 0m13.858s > > at 4 Mbit/s link, while the original 0.56 takes ~55min given the same > > load/network conditions. You may just fix typo and not use other fixes. I doubt they actual for remote fetching. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 12 07:28: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 C4B68567 for ; Fri, 12 Apr 2013 07:28:21 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 5A53F13C8 for ; Fri, 12 Apr 2013 07:28:21 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id k11so1071530eaj.18 for ; Fri, 12 Apr 2013 00:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gul37jcZDIZm0nOlaYUOSlDdSQttDpm3mHr2vI1q9nU=; b=FvouXcBxJRZG8rq2JATzBisY0PT9epN6/bmbM/13oOfwk7scL6RNbz36dJZIPsb9M0 GV+Hh/OlfJ9RPdqqcCKcSSt29FeseUkM+EnNXwGE/eG1wSMQWoDzPAtTNcvw5ldl2w1f jwX62vFc9qJBAOOdcXIfvZria1ep7l5qS0FvU2tWtt13u1a4cEzFdUL9xZnaa6yOmQT1 11yHGuROrKL1dtX2uLutJPWAqnAZkn/GyfLYHHfGV0gv/wfNkgU1jW9bBFL7o7St7FJd udVvj+sOvrIxgOVrUpOBVjULyZu/T7wjx8+vHS7nmHSj4r1x8PT/1nGuuTexACoUEnAN oD8A== X-Received: by 10.15.22.76 with SMTP id e52mr25661458eeu.7.1365751700360; Fri, 12 Apr 2013 00:28:20 -0700 (PDT) Received: from mkushnir.zapto.org (162-69-132-95.pool.ukrtel.net. [95.132.69.162]) by mx.google.com with ESMTPS id t4sm9698674eel.0.2013.04.12.00.28.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Apr 2013 00:28:19 -0700 (PDT) Message-ID: <5167B78A.7070008@gmail.com> Date: Fri, 12 Apr 2013 10:28:10 +0300 From: Markiyan Kushnir User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121119 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? 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: Fri, 12 Apr 2013 07:28:21 -0000 ok, looks like the mere fix to the strlen() call as you suggested earlier doesn't resolve the issue of CPU eating up. On 12.04.2013 08:43, mrboco@gmail.com wrote: > On Friday, April 12, 2013 1:09:53 AM UTC+6, Markiyan Kushnir wrote: >>> Another thing that might be worth of attention, the patched version has >>> been again back to slower checkout time: >>> real 91m38.824s >>> user 0m26.216s >>> sys 0m13.858s >>> at 4 Mbit/s link, while the original 0.56 takes ~55min given the same >>> load/network conditions. > > You may just fix typo and not use other fixes. I doubt they actual for remote fetching. I agree that that long update is not a critical problem per se. People would set up a cron job to run svnup regularly and not be bothered with it. However it might become an inconvenience if one wants to update sources ad-hoc, as for example during solving an issue. The thing is that the proper time to check out a full base/head at 4Mbit/s is 7.5 minutes. And a subsequent update of the tree is proportional to the amount of changes between the revisions, and is often a matter of seconds. It would be nice to get comparable time from svnup. -- Markiyan. > _______________________________________________ > 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 Apr 12 10:14: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 A7AD27B8 for ; Fri, 12 Apr 2013 10:14:05 +0000 (UTC) (envelope-from mrboco@gmail.com) Received: from mail-oa0-f64.google.com (mail-oa0-f64.google.com [209.85.219.64]) by mx1.freebsd.org (Postfix) with ESMTP id 7C9161D6E for ; Fri, 12 Apr 2013 10:14:05 +0000 (UTC) Received: by mail-oa0-f64.google.com with SMTP id m17so720098oag.19 for ; Fri, 12 Apr 2013 03:14:04 -0700 (PDT) X-Received: by 10.49.27.102 with SMTP id s6mr839938qeg.1.1365761644684; Fri, 12 Apr 2013 03:14:04 -0700 (PDT) Path: glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: fa.freebsd.stable Date: Fri, 12 Apr 2013 03:14:04 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=81.30.199.254; posting-account=sMcwMQoAAAAdu1V-A3R0KelfgYVS8M25 NNTP-Posting-Host: 81.30.199.254 References: User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-IP: 81.30.199.254 MIME-Version: 1.0 Message-ID: <6afa3e1a-640d-479f-8e06-ec9cb6a677c2@googlegroups.com> Subject: Re: svn - but smaller? From: mrboco@gmail.com To: fa.freebsd.stable@googlegroups.com 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, 12 Apr 2013 10:14:05 -0000 On Friday, April 12, 2013 1:28:43 PM UTC+6, Markiyan Kushnir wrote: > It would be nice to get comparable time from svnup. I think we could get comparable time only with svn. Sorry. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 12 10:17:20 2013 Return-Path: Delivered-To: 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 1938B8DD for ; Fri, 12 Apr 2013 10:17:20 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) by mx1.freebsd.org (Postfix) with ESMTP id BF6551D93 for ; Fri, 12 Apr 2013 10:17:19 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1UQb2c-0002FW-KN for stable@freebsd.org; Fri, 12 Apr 2013 17:17:10 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id r3CAHqel070852 for ; Fri, 12 Apr 2013 17:17:52 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id r3CAHlrJ070842 for stable@freebsd.org; Fri, 12 Apr 2013 17:17:47 +0700 (NOVT) (envelope-from danfe) Date: Fri, 12 Apr 2013 17:17:46 +0700 From: Alexey Dokuchaev To: stable@freebsd.org Subject: Re: fusefs-kmod does not work on 8-STABLE? Message-ID: <20130412101746.GA68687@regency.nsu.ru> References: <20130410052710.GA36137@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130410052710.GA36137@regency.nsu.ru> User-Agent: Mutt/1.4.2.1i 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, 12 Apr 2013 10:17:20 -0000 On Wed, Apr 10, 2013 at 12:27:10PM +0700, Alexey Dokuchaev wrote: > I've got puzzled with the fact that fusefs-kmod apparently does not on > recent 8-STABLE: it builds and loads, but I don't see normal "fuse4bsd: > version 0.3.9-pre1, FUSE ABI 7.19" like I do on 9-STABLE (installed on the > same laptop with almost identical kernel config). > > The result is that /dev/fuse0 never gets created, and any fuse mount > attempt results in this message: > > fuse: failed to open fuse device: No such file or directory I've traced the problem down a bit, it seems to be due to some weird brokenness of building modules outside the kernel: .ko file loads, but modevent() functions apparently does not execute at all. Also, nvidia.ko can reveal this (or related) bug by spitting messages like this: link_elf: symbol linux_ioctl_unregister_handler undefined This behavior was reported by arundel@ back in 2009 on -current@, but the root cause was never found. http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011975.html http://markmail.org/message/7opthxniqc5ncv6h ./danfe From owner-freebsd-stable@FreeBSD.ORG Fri Apr 12 11:05: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 897429E for ; Fri, 12 Apr 2013 11:05:14 +0000 (UTC) (envelope-from prvs=0814351ecd=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 518EC1F2E for ; Fri, 12 Apr 2013 11:05:13 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UQbn5-000GdO-O1 for freebsd-stable@freebsd.org; Fri, 12 Apr 2013 13:05:11 +0200 Date: Fri, 12 Apr 2013 13:05:11 +0200 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Subject: em driver Update r235527 (May 2012) broke hw csum (at least) Message-ID: <20130412110511.GR79102@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: Fri, 12 Apr 2013 11:05:14 -0000 Hi, just for a short note: I have several servers running FreeBSD 9-STABLE. However, the test of the latest STABLE revisions (machines received no OS updates for over a year, no relevant security updates for my case) brought up stability issues. After giving traffic (over 2 VLANs) to the machine it stalled. I could switch between screens, could not start any command, top/vmstat/... stopped updating. ping was fine. After some time the machine was sometimes back for a few seconds, if I stopped the service (dovecot2, about 800-1500 sessions) I could keep it running sometimes. If I was not able to stop the service in time, the machine kept in "stalled" state until reset. em0@pci0:3:0:0: class=0x020000 card=0x040d15d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82574L Gigabit Network Connection' class = network subclass = ethernet FreeBSD [...] 9.1-STABLE FreeBSD 9.1-STABLE #18 r249361: Thu Apr 11 16:38:17 CEST 2013 root@[...]:/usr/obj/usr/src/sys/APP-64-FBSD9 amd64 Switching off most of the hardware offloading works around the problem: up vlanmtu -tso -lro -rxcsum -txcsum -vlanhwtag -vlanhwcsum -vlantso em0: flags=8843 metric 0 mtu 1500 options=42088 ether 00:25:90:32:e3:a8 inet6 fe80::225:90ff:fe32:e3a8%em0 prefixlen 64 scopeid 0x2 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active Though I wondoer, it still says: VLAN_HWCSUM VLAN_HWTSO in the Options? Interestingly -txcsum -rxcsum was my first test, this alone didn't do the trick (or the interface was already in a state where it wouldn't fully recover). OK, I know: using hw csum is a bad idea anyway, even thogh it seemed to be working for my case up to that point. Does it make sense to dig any deeper or ist it just the way it is and I stumbled over not using best practice up to then? :-) - Oliver -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | From owner-freebsd-stable@FreeBSD.ORG Fri Apr 12 11:42: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 42C718B5 for ; Fri, 12 Apr 2013 11:42:22 +0000 (UTC) (envelope-from feld@feld.me) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by mx1.freebsd.org (Postfix) with ESMTP id 17918142 for ; Fri, 12 Apr 2013 11:42:21 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B63A11B61; Fri, 12 Apr 2013 07:42:20 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute4.internal (MEProxy); Fri, 12 Apr 2013 07:42:20 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=feld.me; h= content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to; s= mesmtp; bh=NI+xCsbt7vw3rNFHHwQ1YZgfob4=; b=VnmD7rEppsNAk5Hlrf+44 0qGMl/ChzESSvaoCOFRmtdIFax8LKVONrWINDC0OtOANtR8W2OJWbH8J8mOXaoBt mNunNIdaDDfYI+1C/9LIgusJHUzpiKF8OGMXgJlPjJIBBqw25XobqKJLcnC5jrW5 H3+A03kTTHsz98YfuhYkbA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:to:subject:references:date :mime-version:content-transfer-encoding:from:message-id :in-reply-to; s=smtpout; bh=NI+xCsbt7vw3rNFHHwQ1YZgfob4=; b=K96v JDo7n7xKvL90Mo0hf9TuiCP5ExAcz7LqFOsItlX28+08QId63gjFNaQ4LkEgj34m 7Zjqw64tL5NLYcy3azcThUF96VrS48+foE2SpXeVnu3Ve45+L3Og4NM6s+cKAjcF wN2dzStQCBV6xyYSyXs3FwTTRMx/jBW0THPWPIU= X-Sasl-enc: NbIN94OKnCWtj/619pUjXZCgscvgtJechfTGtV32dddc 1365766940 Received: from markf.office.supranet.net (unknown [66.170.8.18]) by mail.messagingengine.com (Postfix) with ESMTPA id 5707520015C; Fri, 12 Apr 2013 07:42:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org, "Torfinn Ingolfsen" Subject: Re: fusefs-kmod does not work on 8-STABLE? References: <20130410052710.GA36137@regency.nsu.ru> <20130410205118.72ade1f6495310e84226551b@getmail.no> Date: Fri, 12 Apr 2013 06:42:19 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: <20130410205118.72ade1f6495310e84226551b@getmail.no> User-Agent: Opera Mail/12.14 (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: Fri, 12 Apr 2013 11:42:22 -0000 On Wed, 10 Apr 2013 13:51:18 -0500, Torfinn Ingolfsen wrote: > Ate there any bugreports or known problems? Kernel panics. Lots of them. :) From owner-freebsd-stable@FreeBSD.ORG Fri Apr 12 12:25: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 BB1DD18E for ; Fri, 12 Apr 2013 12:25: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 78AAF34B for ; Fri, 12 Apr 2013 12:25:17 +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 12728033 for freebsd-stable@freebsd.org; Fri, 12 Apr 2013 07:25:11 -0500 From: "John Mehr" Subject: Re: svn - but smaller? To: X-Mailer: CommuniGate Pro WebUser v5.3.11 Date: Fri, 12 Apr 2013 07:25:11 -0500 Message-ID: In-Reply-To: <5167B78A.7070008@gmail.com> References: <5167B78A.7070008@gmail.com> 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: Fri, 12 Apr 2013 12:25:18 -0000 On Fri, 12 Apr 2013 10:28:10 +0300  Markiyan Kushnir wrote: > ok, looks like the mere fix to the strlen() call as you >suggested earlier doesn't resolve the issue of CPU eating >up. > > On 12.04.2013 08:43, mrboco@gmail.com wrote: >> On Friday, April 12, 2013 1:09:53 AM UTC+6, Markiyan >>Kushnir wrote: >>>> Another thing that might be worth of attention, the >>>>patched version has >>>> been again back to slower checkout time: >>>> real    91m38.824s >>>> user    0m26.216s >>>> sys     0m13.858s >>>> at 4 Mbit/s link, while the original 0.56 takes ~55min >>>>given the same >>>> load/network conditions. >> >> You may just fix typo and not use other fixes. I doubt >>they actual for remote fetching. > > I agree that that long update is not a critical problem >per se. People would set up a cron job to run svnup >regularly and not be bothered with it. However it might >become an inconvenience if one wants to update sources >ad-hoc, as for example during solving an issue. The thing >is that the proper time to check out a full base/head at >4Mbit/s is 7.5 minutes. And a subsequent update of the >tree is proportional to the amount of changes between the >revisions, and is often a matter of seconds. It would be >nice to get comparable time from svnup. > > -- > Markiyan. > >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >>"freebsd-stable-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to >"freebsd-stable-unsubscribe@freebsd.org" > Hello, In the previous version (0.61), the process of checking file names against the list of known files in the repository was inefficient and most likely accounts for the slow down you're seeing.  I've reimplemented it using a binary search tree and the lookup phase is no longer a bottleneck. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 12 14:28: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 EDA48FB3 for ; Fri, 12 Apr 2013 14:28:35 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) by mx1.freebsd.org (Postfix) with ESMTP id 9DA70A85 for ; Fri, 12 Apr 2013 14:28:35 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1UQex3-0000cu-FF for stable@freebsd.org; Fri, 12 Apr 2013 21:27:41 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id r3CESOLQ004629 for ; Fri, 12 Apr 2013 21:28:24 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id r3CES3AC004581 for stable@freebsd.org; Fri, 12 Apr 2013 21:28:03 +0700 (NOVT) (envelope-from danfe) Date: Fri, 12 Apr 2013 21:28:02 +0700 From: Alexey Dokuchaev To: stable@freebsd.org Subject: Re: fusefs-kmod does not work on 8-STABLE? Message-ID: <20130412142802.GA1657@regency.nsu.ru> References: <20130410052710.GA36137@regency.nsu.ru> <20130412101746.GA68687@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130412101746.GA68687@regency.nsu.ru> User-Agent: Mutt/1.4.2.1i 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, 12 Apr 2013 14:28:36 -0000 On Fri, Apr 12, 2013 at 05:17:46PM +0700, Alexey Dokuchaev wrote: > On Wed, Apr 10, 2013 at 12:27:10PM +0700, Alexey Dokuchaev wrote: > > I've got puzzled with the fact that fusefs-kmod apparently does not on > > recent 8-STABLE: it builds and loads, but I don't see normal "fuse4bsd: > > version 0.3.9-pre1, FUSE ABI 7.19" like I do on 9-STABLE (installed on the > > same laptop with almost identical kernel config). > > > > The result is that /dev/fuse0 never gets created, and any fuse mount > > attempt results in this message: > > > > fuse: failed to open fuse device: No such file or directory > > I've traced the problem down a bit, it seems to be due to some weird > brokenness of building modules outside the kernel: .ko file loads, but > modevent() functions apparently does not execute at all. I've found the culprit: the problem is in this command of the build: ld -Bshareable -d -warn-common -o hello.ko.debug hello.kld I had put /usr/local/bin in my $PATH before /usr/bin for a reason I don't currently recall, and have binutils-2.23.1 installed. As a result, ld(1) in the quoted line above was called from /usr/local/bin/ld, which brought in all the weird things I was observing: failure of fusefs-kmod, failure of simple "hello world" KLD, "link_elf: symbol undefined" messages when loading snd_hda(4) and nvidia(4) drivers. How, does anyone have a clue why new ld(1) plays so badly with our system toolchain on 8.x (at least)? ./danfe From owner-freebsd-stable@FreeBSD.ORG Fri Apr 12 15:14:43 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 CED34B6E for ; Fri, 12 Apr 2013 15:14:43 +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 B4F7ECDB for ; Fri, 12 Apr 2013 15:14:43 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta12.emeryville.ca.mail.comcast.net with comcast id P0FX1l0051bwxycAC3EjTY; Fri, 12 Apr 2013 15:14:43 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta18.emeryville.ca.mail.comcast.net with comcast id P3Ei1l00D1t3BNj8e3Eies; Fri, 12 Apr 2013 15:14:42 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 04A3473A33; Fri, 12 Apr 2013 08:14:42 -0700 (PDT) Date: Fri, 12 Apr 2013 08:14:42 -0700 From: Jeremy Chadwick To: Alexey Dokuchaev Subject: Re: fusefs-kmod does not work on 8-STABLE? Message-ID: <20130412151441.GA76552@icarus.home.lan> References: <20130410052710.GA36137@regency.nsu.ru> <20130412101746.GA68687@regency.nsu.ru> <20130412142802.GA1657@regency.nsu.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130412142802.GA1657@regency.nsu.ru> 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=1365779683; bh=ftS3eCYyJSrYQXVTDJehrBAcXhYkO7pGVQTnqN5xovA=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=oDPGJItFb0JvykYP90VSCVRFudzTPtFbZnL71tZU2wqaMZnUsQWeNShsFzHayM6iu CSTsri72naJ4FWJ7oLUwRIu/1mw/l6S+p9PWimjVXMYwtfejurGd9Syyt3fNJ/5fKh QnRDBC0oERNC1oFVCIFIZACCjfhfYmIKxA8xMPVGExOYw7PSARX10N3Ewv9yeHI1I6 wc+zjugoOjQeAI8dcndxOaJxLypG5Vroe7hFUH7BpmsLJ5tqKzuaqtHGEM9hc1AkRh d7daeaddQ+NcMd3Un6C7LA9+jtoOcj82DH6tzzjnl72rlEoow5jlHi/A83q3IgHVXd tKGm6JZgrQW6A== 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: Fri, 12 Apr 2013 15:14:43 -0000 On Fri, Apr 12, 2013 at 09:28:02PM +0700, Alexey Dokuchaev wrote: > On Fri, Apr 12, 2013 at 05:17:46PM +0700, Alexey Dokuchaev wrote: > > On Wed, Apr 10, 2013 at 12:27:10PM +0700, Alexey Dokuchaev wrote: > > > I've got puzzled with the fact that fusefs-kmod apparently does not on > > > recent 8-STABLE: it builds and loads, but I don't see normal "fuse4bsd: > > > version 0.3.9-pre1, FUSE ABI 7.19" like I do on 9-STABLE (installed on the > > > same laptop with almost identical kernel config). > > > > > > The result is that /dev/fuse0 never gets created, and any fuse mount > > > attempt results in this message: > > > > > > fuse: failed to open fuse device: No such file or directory > > > > I've traced the problem down a bit, it seems to be due to some weird > > brokenness of building modules outside the kernel: .ko file loads, but > > modevent() functions apparently does not execute at all. > > I've found the culprit: the problem is in this command of the build: > > ld -Bshareable -d -warn-common -o hello.ko.debug hello.kld > > I had put /usr/local/bin in my $PATH before /usr/bin for a reason I don't > currently recall, and have binutils-2.23.1 installed. As a result, ld(1) > in the quoted line above was called from /usr/local/bin/ld, which brought > in all the weird things I was observing: failure of fusefs-kmod, failure > of simple "hello world" KLD, "link_elf: symbol undefined" messages > when loading snd_hda(4) and nvidia(4) drivers. > > How, does anyone have a clue why new ld(1) plays so badly with our system > toolchain on 8.x (at least)? This question might be better-suited for freebsd-hackers@ given its nature. I imagine someone there will have some ideas. :-) HTH! -- | 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 Fri Apr 12 15:36:52 2013 Return-Path: Delivered-To: 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 AA8F1436 for ; Fri, 12 Apr 2013 15:36:52 +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 8FDE9E83 for ; Fri, 12 Apr 2013 15:36:52 +0000 (UTC) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta13.emeryville.ca.mail.comcast.net with comcast id P0xd1l0050cQ2SLAD3csri; Fri, 12 Apr 2013 15:36:52 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta10.emeryville.ca.mail.comcast.net with comcast id P3cr1l00Y1t3BNj8W3crx8; Fri, 12 Apr 2013 15:36:52 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 88CC973A33; Fri, 12 Apr 2013 08:36:51 -0700 (PDT) Date: Fri, 12 Apr 2013 08:36:51 -0700 From: Jeremy Chadwick To: stable@freebsd.org Subject: Re: fusefs-kmod does not work on 8-STABLE? Message-ID: <20130412153651.GA76880@icarus.home.lan> References: <20130410052710.GA36137@regency.nsu.ru> <20130412101746.GA68687@regency.nsu.ru> <20130412142802.GA1657@regency.nsu.ru> <20130412151441.GA76552@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130412151441.GA76552@icarus.home.lan> 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=1365781012; bh=Yt9wbJe9UJ8tko2xOVkk/XYV6AB4BEA46AdkrqVdO6o=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=WdW3jXr9uQfTrWr4hTHqgavcXX7yk2WP6h+jRSZgxJmxoApwMYnmT8MYnaxcV6Ge3 VBTST6TUOZQyVXjNbMIefJxk713QOa5Shxp4H3BfCXTahUAtSNLT92Wdx8QvMFMUHy KDqk5/YSxuUpgJtfwQE8ml4eSm0x//9frx5BP/Z9ISKDIicf+t8qHuRDTVoFAt5Ado V6sPpTFBhNTekAg29T63w4lm//+8k+KBnPImc5R6TLPOUUEJTCqukVUJOOAWvM1EZE pIuKyPUnxj86ZJws3iJUfccrq6vBkUjqXSlnLR+gj8GlNB4JAUhWkIBK6qfIcHZaKD uxiRaUuLuQV9Q== 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, 12 Apr 2013 15:36:52 -0000 On Fri, Apr 12, 2013 at 08:14:42AM -0700, Jeremy Chadwick wrote: > On Fri, Apr 12, 2013 at 09:28:02PM +0700, Alexey Dokuchaev wrote: > > On Fri, Apr 12, 2013 at 05:17:46PM +0700, Alexey Dokuchaev wrote: > > > On Wed, Apr 10, 2013 at 12:27:10PM +0700, Alexey Dokuchaev wrote: > > > > I've got puzzled with the fact that fusefs-kmod apparently does not on > > > > recent 8-STABLE: it builds and loads, but I don't see normal "fuse4bsd: > > > > version 0.3.9-pre1, FUSE ABI 7.19" like I do on 9-STABLE (installed on the > > > > same laptop with almost identical kernel config). > > > > > > > > The result is that /dev/fuse0 never gets created, and any fuse mount > > > > attempt results in this message: > > > > > > > > fuse: failed to open fuse device: No such file or directory > > > > > > I've traced the problem down a bit, it seems to be due to some weird > > > brokenness of building modules outside the kernel: .ko file loads, but > > > modevent() functions apparently does not execute at all. > > > > I've found the culprit: the problem is in this command of the build: > > > > ld -Bshareable -d -warn-common -o hello.ko.debug hello.kld > > > > I had put /usr/local/bin in my $PATH before /usr/bin for a reason I don't > > currently recall, and have binutils-2.23.1 installed. As a result, ld(1) > > in the quoted line above was called from /usr/local/bin/ld, which brought > > in all the weird things I was observing: failure of fusefs-kmod, failure > > of simple "hello world" KLD, "link_elf: symbol undefined" messages > > when loading snd_hda(4) and nvidia(4) drivers. > > > > How, does anyone have a clue why new ld(1) plays so badly with our system > > toolchain on 8.x (at least)? > > This question might be better-suited for freebsd-hackers@ given its > nature. I imagine someone there will have some ideas. :-) HTH! By the way, the mail server for nsu.ru (mail.nsu.ru and mx.nsu.ru) is returning SMTP 550 for your Email address, which a permanent error: > Final-recipient: rfc822; danfe@nsu.ru > Action: failed > Status: 5.1.1 > Diagnostic-Code: smtp; 550 this is wrong, get in touch with postmaster > Last-attempt-Date: Fri, 12 Apr 2013 15:14:50 +0000 -- | 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 Fri Apr 12 17:12:58 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 922CA1ED for ; Fri, 12 Apr 2013 17:12:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 5B02F12E7 for ; Fri, 12 Apr 2013 17:12:58 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::97:e65f:5932:821a] (unknown [IPv6:2001:7b8:3a7:0:97:e65f:5932:821a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E1FD25C44; Fri, 12 Apr 2013 19:12:56 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: fusefs-kmod does not work on 8-STABLE? From: Dimitry Andric In-Reply-To: <20130412142802.GA1657@regency.nsu.ru> Date: Fri, 12 Apr 2013 19:12:39 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20130410052710.GA36137@regency.nsu.ru> <20130412101746.GA68687@regency.nsu.ru> <20130412142802.GA1657@regency.nsu.ru> To: Alexey Dokuchaev X-Mailer: Apple Mail (2.1503) 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: Fri, 12 Apr 2013 17:12:58 -0000 On Apr 12, 2013, at 16:28, Alexey Dokuchaev wrote: ... > I've found the culprit: the problem is in this command of the build: > > ld -Bshareable -d -warn-common -o hello.ko.debug hello.kld > > I had put /usr/local/bin in my $PATH before /usr/bin for a reason I don't > currently recall, and have binutils-2.23.1 installed. As a result, ld(1) > in the quoted line above was called from /usr/local/bin/ld, which brought > in all the weird things I was observing: failure of fusefs-kmod, failure > of simple "hello world" KLD, "link_elf: symbol undefined" messages > when loading snd_hda(4) and nvidia(4) drivers. > > How, does anyone have a clue why new ld(1) plays so badly with our system > toolchain on 8.x (at least)? Maybe because there is almost 10 years difference between those implementations? :-) In any case, to figure out what is different, just try linking the kernel module with the system ld and the ports ld, and comparing "readelf -a" output. Or upload both module versions somewhere, so we can all have a look. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 12 23:38:42 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 73D5421C for ; Fri, 12 Apr 2013 23:38:42 +0000 (UTC) (envelope-from jcm@visi.com) Received: from g2host.com (mailback3.g2host.com [208.42.184.243]) by mx1.freebsd.org (Postfix) with ESMTP id 412B230F for ; Fri, 12 Apr 2013 23:38:41 +0000 (UTC) Received: from [208.42.90.57] (account jcm@visi.com) by mailback3.g2host.com (CommuniGate Pro WEBUSER 5.3.11) with HTTP id 11604093 for freebsd-stable@freebsd.org; Fri, 12 Apr 2013 18:38:35 -0500 From: "John Mehr" Subject: Re: svn - but smaller? To: X-Mailer: CommuniGate Pro WebUser v5.3.11 Date: Fri, 12 Apr 2013 18:38:35 -0500 Message-ID: In-Reply-To: <0025e959-80c1-417f-9ed5-aeff3c00b05a@googlegroups.com> References: <88b872cf-7795-4d69-91c7-6c3107299b33@googlegroups.com> <0025e959-80c1-417f-9ed5-aeff3c00b05a@googlegroups.com> 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: Fri, 12 Apr 2013 23:38:42 -0000 On Thu, 11 Apr 2013 01:39:32 -0700 (PDT)  mrboco@gmail.com wrote: > On Thursday, April 11, 2013 1:14:57 PM UTC+6, >mrb...@gmail.com wrote: >> I've placed the patched svnup.c (0.56), the diff and two >>statically linked binaries on >>http://ftp.ufanet.ru/pub/boco/freebsd/svnup/ > > I'm sorry, svnup.c.diff is the patch against filtered >thru indent svnup.c, with different formatting (see >README). > > The patch against the original svnup.c v0.56 is named >svnup.c.diff-original. > _______________________________________________ > 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, Speaking of indent(1), does anyone know of a set of command line parameters that can reformat source code to style(9) guidelines (or a close approximation)?  Thanks. From owner-freebsd-stable@FreeBSD.ORG Sat Apr 13 01:22:02 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 3D104C81 for ; Sat, 13 Apr 2013 01:22:02 +0000 (UTC) (envelope-from dparussalla@baysidegrp.com.au) Received: from baysidegrp.com.au (gateway.baysidegrp.com.au [61.88.141.194]) by mx1.freebsd.org (Postfix) with ESMTP id A172583E for ; Sat, 13 Apr 2013 01:22:00 +0000 (UTC) Received: (qmail 54800 invoked by uid 0); 13 Apr 2013 11:15:18 +1000 Received: by simscan 1.4.0 ppid: 54796, pid: 54797, t: 0.0067s scanners: attach: 1.4.0 clamav: 0.97.6/m: Received: from localhost (HELO mail.baysidegrp.com.au) (127.0.0.1) by baysidegrp.com.au with ESMTP; 13 Apr 2013 11:15:18 +1000 Received: from 150.101.163.50 (SquirrelMail authenticated user dparussalla@baysidegrp.com.au) by mail.baysidegrp.com.au with HTTP; Sat, 13 Apr 2013 11:15:18 +1000 (EST) Message-ID: <49725.150.101.163.50.1365815718.squirrel@mail.baysidegrp.com.au> Date: Sat, 13 Apr 2013 11:15:18 +1000 (EST) Subject: gnutls compile issues From: dparussalla@baysidegrp.com.au To: stable@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 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, 13 Apr 2013 01:22:02 -0000 Hi All, I am having issues compiling gnutls-2.12.23 on Freebsd 6.4 stable platform. Please find the following errors. Any help much appropriated. checking whether uses 'inline' correctly... no configure: error: cannot be used with this compiler (cc -std=gnu99 -O2 -fno-strict-aliasing -pipe -I/usr/local/include/p11-kit-1 -I/usr/local/include -fPIC -D_THREAD_SAFE). This is a known interoperability problem of glibc <= 2.5 with gcc >= 4.3 in C99 mode. You have four options: - Add the flag -fgnu89-inline to CC and reconfigure, or - Fix your include files, using parts of , or - Use a gcc version older than 4.3, or - Don't use the flags -std=c99 or -std=gnu99. Configuration aborted. ===> Script "configure" failed unexpectedly. Please report the problem to novel@FreeBSD.org [maintainer] and attach the From owner-freebsd-stable@FreeBSD.ORG Sat Apr 13 06:42:05 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 147B1354; Sat, 13 Apr 2013 06:42:05 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) by mx1.freebsd.org (Postfix) with ESMTP id B8258214; Sat, 13 Apr 2013 06:42:04 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1UQu9K-0004s0-L8; Sat, 13 Apr 2013 13:41:22 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id r3D6g7kw079697; Sat, 13 Apr 2013 13:42:07 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id r3D6fo9Z079639; Sat, 13 Apr 2013 13:41:50 +0700 (NOVT) (envelope-from danfe) Date: Sat, 13 Apr 2013 13:41:50 +0700 From: Alexey Dokuchaev To: Dimitry Andric Subject: Re: fusefs-kmod does not work on 8-STABLE? Message-ID: <20130413064150.GA72951@regency.nsu.ru> References: <20130410052710.GA36137@regency.nsu.ru> <20130412101746.GA68687@regency.nsu.ru> <20130412142802.GA1657@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i 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, 13 Apr 2013 06:42:05 -0000 On Fri, Apr 12, 2013 at 07:12:39PM +0200, Dimitry Andric wrote: > > Does anyone have a clue why new ld(1) plays so badly with our system > > toolchain on 8.x (at least)? > > Maybe because there is almost 10 years difference between those > implementations? :-) > > In any case, to figure out what is different, just try linking the > kernel module with the system ld and the ports ld, and comparing > "readelf -a" output. Good idea. I've uploaded both outputs if someone wants to take a look. Not surprisingly, "bad" output is shorter: readelf(1) reported only 16 section headers vs. "good" 18 (missing .got, .gnu_debuglink, and empty .bss, yet having .eh_frame instead). Haven't look more closely yet: http://193.124.210.26/readelf.bad http://193.124.210.26/readelf.good > Or upload both module versions somewhere, so we can all have a look. Sure, at the same URL, hello{.c,_bad.ko,_good.ko}. Although it should be pretty easy to reproduce locally: just install fresh devel/binutils, put $localbase/bin in front of your $path, and rebuild hello.ko (or any your favorite module). ./danfe From owner-freebsd-stable@FreeBSD.ORG Sat Apr 13 07:38: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 10D38C62 for ; Sat, 13 Apr 2013 07:38:08 +0000 (UTC) (envelope-from mrboco@gmail.com) Received: from mail-da0-x23d.google.com (mail-da0-x23d.google.com [IPv6:2607:f8b0:400e:c00::23d]) by mx1.freebsd.org (Postfix) with ESMTP id E70E43EA for ; Sat, 13 Apr 2013 07:38:07 +0000 (UTC) Received: by mail-da0-f61.google.com with SMTP id p5so971249dak.16 for ; Sat, 13 Apr 2013 00:38:07 -0700 (PDT) X-Received: by 10.49.2.170 with SMTP id 10mr1149264qev.40.1365838687323; Sat, 13 Apr 2013 00:38:07 -0700 (PDT) Path: glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: fa.freebsd.stable Date: Sat, 13 Apr 2013 00:38:07 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=81.30.199.254; posting-account=sMcwMQoAAAAdu1V-A3R0KelfgYVS8M25 NNTP-Posting-Host: 81.30.199.254 References: User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-IP: 81.30.199.254 MIME-Version: 1.0 Message-ID: <55f7d158-b02d-49f4-8181-8711be8d5647@googlegroups.com> Subject: Re: svn - but smaller? From: mrboco@gmail.com To: fa.freebsd.stable@googlegroups.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 13 Apr 2013 07:38:08 -0000 > In the previous version (0.61), the process of checking=20 > file names against the list of known files in the=20 > repository was inefficient and most likely accounts for=20 > the slow down you're seeing.=A0 I've reimplemented it using=20 > a binary search tree and the lookup phase is no longer a=20 > bottleneck. I'm sorry but 0.62 still locks while fetching from a local repository: last pid: 74701; load averages: 2.24, 2.52, 2.56 = up 772+03:32:23 13:19:55 96 processes: 2 running, 94 sleeping CPU: 14.8% user, 0.0% nice, 40.3% system, 0.7% interrupt, 44.2% idle Mem: 1191M Active, 436M Inact, 248M Wired, 76M Cache, 112M Buf, 50M Free Swap: 1024M Total, 232M Used, 792M Free, 22% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 30193 root 1 117 0 56220K 9108K CPU1 1 99:16 96.39% svnup The send/receive queues are filled up and not changing over time: root@alpha:~# netstat -an | fgrep -w 3690 tcp4 8192 24576 81.30.199.66.3690 81.30.199.66.44473 ESTABLISH= ED tcp4 24576 16384 81.30.199.66.44473 81.30.199.66.3690 ESTABLISH= ED tcp4 0 0 *.3690 *.* LISTEN root@alpha:~# kdump | head -40 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) 30193 svnup RET write -1 errno 35 Resource temporarily unavailable 30193 svnup CALL write(0x3,0x8843a000,0xd91) I think you should either use blocking IO or catch IO errors. And please co= nsider to set the socket options too. Thanks. From owner-freebsd-stable@FreeBSD.ORG Sat Apr 13 08:19:23 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 5247436B for ; Sat, 13 Apr 2013 08:19:23 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id DC53A7BD for ; Sat, 13 Apr 2013 08:19:22 +0000 (UTC) Received: by mail-ea0-f178.google.com with SMTP id o10so1562688eaj.23 for ; Sat, 13 Apr 2013 01:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=XMxWdIPymqkl085l20vlMeN1CwVF4S8toL0l87E1JW4=; b=AB/1IterhmtBNAaqCcXtDBYknyZT+tcD49SCeGddJRnw2qf2RlUv95Dm2tk8wN6EeD zEEObryeudhDSoPPVSk2XTRHfAynRLUB48Cy4IRH4ntttM3V6viLZjfvs51qGxPIZlF4 u0L8TaHwzykw+NxbELBtdteTQZH3TJNVGhGr1FsmE07U9FJpSy5M4JqHNkqekpwwAm9k yRXFTZbkAKzhvd4OXyB0G+WjmJbS60VUsW3eSnCRPD2GZnEDNDi29JXdl7/Hxy18fUkC AIloDdTuIuccwpZfjgPjPRbDGIJFeSPVuudy7CEufkDO961uKhjk2KXKJ1/QZfFDVYG0 hivQ== X-Received: by 10.15.41.2 with SMTP id r2mr36763476eev.20.1365841161967; Sat, 13 Apr 2013 01:19:21 -0700 (PDT) Received: from mkushnir.zapto.org (254-173-124-91.pool.ukrtel.net. [91.124.173.254]) by mx.google.com with ESMTPS id ca4sm15102787eeb.15.2013.04.13.01.19.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Apr 2013 01:19:21 -0700 (PDT) Message-ID: <516914FE.4090306@gmail.com> Date: Sat, 13 Apr 2013 11:19:10 +0300 From: Markiyan Kushnir User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121119 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? References: <88b872cf-7795-4d69-91c7-6c3107299b33@googlegroups.com> <0025e959-80c1-417f-9ed5-aeff3c00b05a@googlegroups.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: Sat, 13 Apr 2013 08:19:23 -0000 here is what I used to use (not 100% match, but quite close): indent -bad -bap -bbb -d4 -di1 -fc1 -i4 -nip -npsl -nut $* -- Markiyan. On 13.04.2013 02:38, John Mehr wrote: > > > > On Thu, 11 Apr 2013 01:39:32 -0700 (PDT) > mrboco@gmail.com wrote: >> On Thursday, April 11, 2013 1:14:57 PM UTC+6, mrb...@gmail.com wrote: >>> I've placed the patched svnup.c (0.56), the diff and two statically >>> linked binaries on http://ftp.ufanet.ru/pub/boco/freebsd/svnup/ >> >> I'm sorry, svnup.c.diff is the patch against filtered thru indent >> svnup.c, with different formatting (see README). >> >> The patch against the original svnup.c v0.56 is named >> svnup.c.diff-original. >> _______________________________________________ >> 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, > > Speaking of indent(1), does anyone know of a set of command line > parameters that can reformat source code to style(9) guidelines (or a > close approximation)? Thanks. > _______________________________________________ > 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 Sat Apr 13 08:29: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 DA0E1716 for ; Sat, 13 Apr 2013 08:29:55 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by mx1.freebsd.org (Postfix) with ESMTP id 70F9A833 for ; Sat, 13 Apr 2013 08:29:54 +0000 (UTC) Received: by mail-ee0-f50.google.com with SMTP id e53so1592111eek.23 for ; Sat, 13 Apr 2013 01:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=MlFmpPIsvrShZEutMRzhbVpr+2WQ01KOUIlJgNYSMjo=; b=T9eW8PRCPglA0fcY2sJVmfFChpacSABEf+I1KovAoLzdqAEv+GUTkpzG83zoEqOaj5 SjdiP4obXp6bdvWTh7Q0IQ7oVyq9qbKtgIT/w+BzdX3xlqnJDtcAN4x1QHjUs6RyvCfq V5F0AHo6nSnk6epUo5C66dtM5xpkoSeDQQnxJEFwv/lSaVGj8AEZIFL31qTK2rIdSiyD ijhZHwrbihnn0f9sOEvY15CqKY/IT/1iPtgqC7Q+FcsjCwbE5aeyW4CXbSCwGhus+ItD 27OHaRdQc29DQaoS9v8eEC5tBa5JuhfzQn0nmNKkhHHh9CDI1AGPdOt7q6R7X2uAe8aK IRYA== X-Received: by 10.15.76.132 with SMTP id n4mr36825674eey.16.1365841793193; Sat, 13 Apr 2013 01:29:53 -0700 (PDT) Received: from mkushnir.zapto.org (254-173-124-91.pool.ukrtel.net. [91.124.173.254]) by mx.google.com with ESMTPS id a41sm15254082eei.4.2013.04.13.01.29.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Apr 2013 01:29:52 -0700 (PDT) Message-ID: <51691775.3000006@gmail.com> Date: Sat, 13 Apr 2013 11:29:41 +0300 From: Markiyan Kushnir User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121119 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? References: <55f7d158-b02d-49f4-8181-8711be8d5647@googlegroups.com> In-Reply-To: <55f7d158-b02d-49f4-8181-8711be8d5647@googlegroups.com> 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: Sat, 13 Apr 2013 08:29:55 -0000 The only thing I would like to add -- tree lookup did make a good effect on CPU consumption. -- Markiyan. On 13.04.2013 10:38, mrboco@gmail.com wrote: >> In the previous version (0.61), the process of checking >> file names against the list of known files in the >> repository was inefficient and most likely accounts for >> the slow down you're seeing. I've reimplemented it using >> a binary search tree and the lookup phase is no longer a >> bottleneck. > > I'm sorry but 0.62 still locks while fetching from a local repository: > > last pid: 74701; load averages: 2.24, 2.52, 2.56 up 772+03:32:23 13:19:55 > 96 processes: 2 running, 94 sleeping > CPU: 14.8% user, 0.0% nice, 40.3% system, 0.7% interrupt, 44.2% idle > Mem: 1191M Active, 436M Inact, 248M Wired, 76M Cache, 112M Buf, 50M Free > Swap: 1024M Total, 232M Used, 792M Free, 22% Inuse > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 30193 root 1 117 0 56220K 9108K CPU1 1 99:16 96.39% svnup > > The send/receive queues are filled up and not changing over time: > > root@alpha:~# netstat -an | fgrep -w 3690 > tcp4 8192 24576 81.30.199.66.3690 81.30.199.66.44473 ESTABLISHED > tcp4 24576 16384 81.30.199.66.44473 81.30.199.66.3690 ESTABLISHED > tcp4 0 0 *.3690 *.* LISTEN > > root@alpha:~# kdump | head -40 > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > 30193 svnup RET write -1 errno 35 Resource temporarily unavailable > 30193 svnup CALL write(0x3,0x8843a000,0xd91) > > I think you should either use blocking IO or catch IO errors. And please consider to set the socket options too. > > Thanks. > _______________________________________________ > 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 Sat Apr 13 11:41:59 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 9F242389 for ; Sat, 13 Apr 2013 11:41:59 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 34A2AF1C for ; Sat, 13 Apr 2013 11:41:59 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id q14so1530812eaj.36 for ; Sat, 13 Apr 2013 04:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4y/1qFj2H7FZ8KAUOj8vLijgj9btisunO2d8Wszg+Vc=; b=Nqn0ncZGSqlYluCpq/tJs1F9gOnuJ9HTRjmmq4yATFEOrko5uhl+cA9D3ifKdjcq5q jYlYH1ZkdbaGDNi4KM9hf87evDF5e80hIFOZ7tfVv6gkoBjvOq3QD2Dl/b+00WuEt2CL juhXHDrWgqEVLfMkwa+U7y/TG9xDEnfTVdjYAqR0fZNTU4LlhqT7+sJ+ZIY5SgT8k9ca 4db276+GL/VEMHMYSSFLEy5d8Jo/NnbXjqs3HiK66rjNRq7yDZcxTDZZVhXlH3NfVBZ5 n1u5wx4UThmsdC/o4MS0QoharsYoFL1H7v7bG6ZfNJaVWMZUuv+a19/g74k+OUyeV6CT /4hQ== X-Received: by 10.14.214.65 with SMTP id b41mr38712995eep.37.1365853318207; Sat, 13 Apr 2013 04:41:58 -0700 (PDT) Received: from mkushnir.zapto.org (221-139-132-95.pool.ukrtel.net. [95.132.139.221]) by mx.google.com with ESMTPS id q5sm15914612eeo.17.2013.04.13.04.41.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Apr 2013 04:41:57 -0700 (PDT) Message-ID: <5169447A.6020904@gmail.com> Date: Sat, 13 Apr 2013 14:41:46 +0300 From: Markiyan Kushnir User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121119 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: svn - but smaller? References: <55f7d158-b02d-49f4-8181-8711be8d5647@googlegroups.com> <51691775.3000006@gmail.com> In-Reply-To: <51691775.3000006@gmail.com> 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: Sat, 13 Apr 2013 11:41:59 -0000 On 13.04.2013 11:29, Markiyan Kushnir wrote: > The only thing I would like to add -- tree lookup did make a good effect > on CPU consumption. > John, I'm just curious, did you consider sys/tree.h for tree implementation? I realize that it wouldn't be well portable to Linux. Any way, did you have other considerations to use your own tree implementation in svnup? -- Markiyan. > -- > Markiyan. > > > On 13.04.2013 10:38, mrboco@gmail.com wrote: >>> In the previous version (0.61), the process of checking >>> file names against the list of known files in the >>> repository was inefficient and most likely accounts for >>> the slow down you're seeing. I've reimplemented it using >>> a binary search tree and the lookup phase is no longer a >>> bottleneck. >> >> I'm sorry but 0.62 still locks while fetching from a local repository: >> >> last pid: 74701; load averages: 2.24, 2.52, >> 2.56 up 772+03:32:23 13:19:55 >> 96 processes: 2 running, 94 sleeping >> CPU: 14.8% user, 0.0% nice, 40.3% system, 0.7% interrupt, 44.2% idle >> Mem: 1191M Active, 436M Inact, 248M Wired, 76M Cache, 112M Buf, 50M Free >> Swap: 1024M Total, 232M Used, 792M Free, 22% Inuse >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >> COMMAND >> 30193 root 1 117 0 56220K 9108K CPU1 1 99:16 96.39% svnup >> >> The send/receive queues are filled up and not changing over time: >> >> root@alpha:~# netstat -an | fgrep -w 3690 >> tcp4 8192 24576 81.30.199.66.3690 81.30.199.66.44473 >> ESTABLISHED >> tcp4 24576 16384 81.30.199.66.44473 81.30.199.66.3690 >> ESTABLISHED >> tcp4 0 0 *.3690 *.* LISTEN >> >> root@alpha:~# kdump | head -40 >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> 30193 svnup RET write -1 errno 35 Resource temporarily unavailable >> 30193 svnup CALL write(0x3,0x8843a000,0xd91) >> >> I think you should either use blocking IO or catch IO errors. And >> please consider to set the socket options too. >> >> Thanks. >> _______________________________________________ >> 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 Sat Apr 13 11:52:41 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 D89B961E for ; Sat, 13 Apr 2013 11:52:41 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id A2CD1F7D for ; Sat, 13 Apr 2013 11:52:41 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::3031:e968:43b2:9c42] (unknown [IPv6:2001:7b8:3a7:0:3031:e968:43b2:9c42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 814505C44; Sat, 13 Apr 2013 13:52:38 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: gnutls compile issues From: Dimitry Andric In-Reply-To: <49725.150.101.163.50.1365815718.squirrel@mail.baysidegrp.com.au> Date: Sat, 13 Apr 2013 13:52:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <165AD359-E8E3-4201-B070-5A6B3C452BD8@FreeBSD.org> References: <49725.150.101.163.50.1365815718.squirrel@mail.baysidegrp.com.au> To: dparussalla@baysidegrp.com.au X-Mailer: Apple Mail (2.1503) 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, 13 Apr 2013 11:52:41 -0000 On Apr 13, 2013, at 03:15, dparussalla@baysidegrp.com.au wrote: > I am having issues compiling gnutls-2.12.23 on Freebsd 6.4 stable > platform. Please find the following errors. >=20 > Any help much appropriated. >=20 > checking whether uses 'inline' correctly... no > configure: error: cannot be used with this compiler (cc > -std=3Dgnu99 -O2 -fno-strict-aliasing -pipe = -I/usr/local/include/p11-kit-1 =20 > -I/usr/local/include -fPIC -D_THREAD_SAFE). > This is a known interoperability problem of glibc <=3D 2.5 with gcc >=3D= 4.3 in > C99 mode. You have four options: > - Add the flag -fgnu89-inline to CC and reconfigure, or > - Fix your include files, using parts of > = , > or > - Use a gcc version older than 4.3, or > - Don't use the flags -std=3Dc99 or -std=3Dgnu99. Let me start by saying 6.4 is totally unsupported, but you are most likely aware of that. :-) That said, I don't think 6.4 already had complete C99 support, so this is probably why the configure script fails. You can see the script itself gives you a few hints for a workaround. Since 6.4 is already using a gcc version older than 4.3, and the "fix your include files" hint is only valid for glibc, the best option is to make sure -std=3Dc99 or -std=3Dgnu99 is *not* used. For example, if you are building this manually, try setting ac_cv_prog_cc_c99=3Dno in configure's environment, like so: ac_cv_prog_cc_c99=3Dno ./configure If you are building this from the port, try adding a line: CONFIGURE_ENV+=3D ac_cv_prog_cc_c99=3Dno in the port's Makefile. From owner-freebsd-stable@FreeBSD.ORG Sat Apr 13 12:29:43 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 E52F02EF; Sat, 13 Apr 2013 12:29:43 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by mx1.freebsd.org (Postfix) with ESMTP id 53EAF1C9; Sat, 13 Apr 2013 12:29:43 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hr17so327219wib.11 for ; Sat, 13 Apr 2013 05:29:42 -0700 (PDT) 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=XKfYQMYnKdLwGo4fhASdqsVuSXG+yw974gbsMmOdoAs=; b=I43qzTNZkooWY55qWwEIzu9pjJ84VndfQckqhoI5qTOHvkC9fG4Btrv8O9KuoQIarl lyW6kDZC2lgzOntwzUFRcrolkSyUoxKBvLvK3RAA61HkSVuQYRpT6rNXRZQyKCdrsJgs JmRzxAQ9EO/yrw607E+STriF2LafOvS2lTPmL3GVic6JQbF6AOm5aWcgX7GrnbckrDCS AGRQ8VQFF8FyaI8wLUaDbEHFG0obYBOmnTQX4pOS+Gte/2ZNrgQE4aB6CBBHbhaeemPO jEVoZenISinsUxi0j8VmMpcXtqTjKTKBDvDZ7rJ4I/p8h59sHnGS94eYaINbDIqxL7o0 daYw== MIME-Version: 1.0 X-Received: by 10.194.60.195 with SMTP id j3mr22818693wjr.33.1365856182448; Sat, 13 Apr 2013 05:29:42 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Sat, 13 Apr 2013 05:29:42 -0700 (PDT) In-Reply-To: References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> <20121222171400.GA2399@anubis.morrow.me.uk> <50D5F296.9050109@wasikowski.net> Date: Sat, 13 Apr 2013 15:29:42 +0300 Message-ID: Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: Kimmo Paasiala To: FreeBSD current Content-Type: text/plain; charset=UTF-8 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, 13 Apr 2013 12:29:44 -0000 On Thu, Jan 17, 2013 at 7:24 AM, Kimmo Paasiala wrote: > On Thu, Dec 27, 2012 at 11:42 PM, Phil Kulin wrote: >> 2012/12/26 Kimmo Paasiala : >> >>> I've revised the patch again and updated it at gihub, >>> https://gist.github.com/4362018. It can now be applied at top level >>> of sources (/usr/src typically). It now does the deconfiguration in >>> reverse order of the configuration, meaning the aliases configured >>> with ipv6_addrs_IF are removed before the ones configured with >>> ifconfig_IF_aliasN="inet6 ...". >> >> Adapted for FreeBSD 8.2, works fine: >> >> --- network.subr.orig 2011-02-17 05:19:39.000000000 +0300 >> +++ network.subr 2012-12-28 00:46:38.000000000 +0400 >> @@ -312,6 +312,12 @@ afexists() >> # 1 otherwise. >> ipv6if() >> { >> + # Test for $ipv6_addrs_IF. If it exists then the >> + # interface should be configured for IPv6 >> + _tmpargs=$(get_if_var $_if ipv6_addrs_IF) >> + if [ -n "${_tmpargs}" ]; then >> + return 0 >> + fi >> if ! checkyesno ipv6_enable; then >> return 1 >> fi >> @@ -948,7 +954,12 @@ network6_interface_setup() >> rtsol_interface=no >> ifconfig $i inet6 ${ipv6_ifconfig} alias >> fi >> - >> + ipv6_addrs=`get_if_var $i ipv6_addrs_IF` >> + if [ -n "${ipv6_addrs}" ]; then >> + rtsol_available=no >> + rtsol_interface=no >> + ipv6_addrs_common ${i} alias >> + fi >> # Wireless NIC cards are virtualized through the wlan interface >> if ! is_wired_interface ${i}; then >> case "${i}" in >> @@ -1178,3 +1189,39 @@ network6_getladdr() >> esac >> done >> } >> + >> +ipv6_addrs_common() >> +{ >> + local _ret _if _action _ip6prefix _ip6prefixes >> + local _ip6addr _prefixlen >> + local _range _ip6net _ip6low _ip6high >> + _ret=1 >> + _if=$1 >> + _action=$2 >> + # get the prefixes from ipv6_addrs_IF variable >> + _ip6prefixes=`get_if_var $_if ipv6_addrs_IF` >> + for _ip6prefix in ${_ip6prefixes}; do >> + _ip6addr=${_ip6prefix%%/*} >> + _prefixlen=${_ip6prefix##*/} >> + _range=${_ip6addr##*:} >> + _ip6net=${_ip6addr%:*} >> + _ip6low=${_range%-*} >> + _ip6high=${_range#*-} >> + # If deleting an alias, set _prefixlen to null string. >> + if [ "${_action}" = "-alias" ]; then >> + _prefixlen="" >> + else >> + _prefixlen="prefixlen $_prefixlen" >> + fi >> + _ip6high=$(("0x${_ip6high}")) >> + _ip6count=$(("0x${_ip6low}")) >> + while [ "${_ip6count}" -le "${_ip6high}" ]; do >> + # Re-uses the _ip6addr variable from above >> + _ip6addr=$(printf "%x" "${_ip6count}") >> + eval "ifconfig ${_if} inet6 >> ${_ip6net}:${_ip6addr} ${_prefixlen} ${_action}" >> + _ip6count=$((${_ip6count}+1)) >> + _ret=0 >> + done >> + done >> + return $_ret >> +} >> >> >> -- >> Non nobis Domine non nobis sed Nomini Tuo da gloriam >> Phil Kulin > > I don't have an 8.X system to test but I guess it's fine. > > Any more interest in this? I'd love to see this added, not because I > wrote it but because I want to contribute in any way I can. > > -Kimmo Sorry to resurrect this thread but since nothing has happened in about three months I have to ask: What can I do to have this commited to HEAD? I'd be even willing to become a src committer if that's what is required. I feel that I'm compentent enough. Who can I contact? -Kimmo From owner-freebsd-stable@FreeBSD.ORG Sat Apr 13 20:16:03 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 7D4A5BF3; Sat, 13 Apr 2013 20:16:03 +0000 (UTC) (envelope-from trashcan@t-online.de) Received: from mailout02.t-online.de (mailout02.t-online.de [194.25.134.17]) by mx1.freebsd.org (Postfix) with ESMTP id 36CD31259; Sat, 13 Apr 2013 20:16:03 +0000 (UTC) Received: from fwd50.aul.t-online.de (fwd50.aul.t-online.de ) by mailout02.t-online.de with smtp id 1UR6ri-00067P-2c; Sat, 13 Apr 2013 22:16:02 +0200 Received: from sulu.fritz.box (X7tOLvZQrhV3AQxWvWJdKRbCs1OrpSWkZLsQPtcWNhW9qc-hB+BgNvPExegwkaoZ5L@[62.226.251.113]) by fwd50.t-online.de with esmtp id 1UR6rZ-0BqTdA0; Sat, 13 Apr 2013 22:15:53 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipv6_addrs_IF aliases in rc.conf(5) From: "Michael Grimm" In-Reply-To: Date: Sat, 13 Apr 2013 22:15:53 +0200 Content-Transfer-Encoding: 7bit Message-Id: <4476561A-43B6-4A7F-B0E9-EB40F7C1177C@odo.in-berlin.de> References: <50D1C553.9060100@wasikowski.net> <20121220132750.GB99616@stack.nl> <50D4F2E4.7020600@wasikowski.net> <20121222171400.GA2399@anubis.morrow.me.uk> <50D5F296.9050109@wasikowski.net> To: freebsd-stable@freebsd.org, FreeBSD current X-Mailer: Apple Mail (2.1503) X-ID: X7tOLvZQrhV3AQxWvWJdKRbCs1OrpSWkZLsQPtcWNhW9qc-hB+BgNvPExegwkaoZ5L X-TOI-MSGID: ba5352f5-0b1b-4b64-8271-64f3f2fddae9 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, 13 Apr 2013 20:16:03 -0000 Hi -- On 13.04.2013, at 14:29, Kimmo Paasiala wrote: [great deal of simplification by ipv6_addrs_IF] > Sorry to resurrect this thread but since nothing has happened in about > three months I have to ask: What can I do to have this commited to > HEAD? +1 Nowadays -where IPv6 becomes more and more available by ISPs- I *really* would like to see this simplification implemented, soon, very soon. The current scheme is way to much error prone, and, its a pain in the ass! Thanks for the patch, Michael From owner-freebsd-stable@FreeBSD.ORG Sat Apr 13 21:06:43 2013 Return-Path: Delivered-To: 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 82D52456 for ; Sat, 13 Apr 2013 21:06:43 +0000 (UTC) (envelope-from dparussalla@baysidegrp.com.au) Received: from baysidegrp.com.au (gateway.baysidegrp.com.au [61.88.141.194]) by mx1.freebsd.org (Postfix) with ESMTP id E405413A9 for ; Sat, 13 Apr 2013 21:06:42 +0000 (UTC) Received: (qmail 27389 invoked by uid 0); 14 Apr 2013 07:06:41 +1000 Received: by simscan 1.4.0 ppid: 27385, pid: 27386, t: 0.0084s scanners: attach: 1.4.0 clamav: 0.97.6/m: Received: from localhost (HELO mail.baysidegrp.com.au) (127.0.0.1) by baysidegrp.com.au with ESMTP; 14 Apr 2013 07:06:41 +1000 Received: from 150.101.163.50 (SquirrelMail authenticated user dparussalla@baysidegrp.com.au) by mail.baysidegrp.com.au with HTTP; Sun, 14 Apr 2013 07:06:41 +1000 (EST) Message-ID: <25242.150.101.163.50.1365887201.squirrel@mail.baysidegrp.com.au> In-Reply-To: <165AD359-E8E3-4201-B070-5A6B3C452BD8@FreeBSD.org> References: <49725.150.101.163.50.1365815718.squirrel@mail.baysidegrp.com.au> <165AD359-E8E3-4201-B070-5A6B3C452BD8@FreeBSD.org> Date: Sun, 14 Apr 2013 07:06:41 +1000 (EST) Subject: Re: gnutls compile issues From: dparussalla@baysidegrp.com.au To: "Dimitry Andric" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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, 13 Apr 2013 21:06:43 -0000 Thanks Dimitry, I've tried with the ENV variable in the Makefile. But still getting the same error. Any other ideas? I need to get the gnutls working on this system. Cheers, On Sat, April 13, 2013 21:52, Dimitry Andric wrote: > On Apr 13, 2013, at 03:15, dparussalla@baysidegrp.com.au wrote: > >> I am having issues compiling gnutls-2.12.23 on Freebsd 6.4 stable >> platform. Please find the following errors. >> >> Any help much appropriated. >> >> >> checking whether uses 'inline' correctly... no configure: >> error: cannot be used with this compiler (cc >> -std=gnu99 -O2 -fno-strict-aliasing -pipe -I/usr/local/include/p11-kit-1 >> -I/usr/local/include -fPIC -D_THREAD_SAFE). >> This is a known interoperability problem of glibc <= 2.5 with gcc >= 4.3 >> in C99 mode. You have four options: >> - Add the flag -fgnu89-inline to CC and reconfigure, or >> - Fix your include files, using parts of >> > 0d706c2e18c929d0e69a621>, >> or - Use a gcc version older than 4.3, or >> - Don't use the flags -std=c99 or -std=gnu99. >> > > > Let me start by saying 6.4 is totally unsupported, but you are most > likely aware of that. :-) > > That said, I don't think 6.4 already had complete C99 support, so this > is probably why the configure script fails. You can see the script itself > gives you a few hints for a workaround. Since 6.4 is already using a gcc > version older than 4.3, and the "fix your include files" hint is only > valid for glibc, the best option is to make sure -std=c99 or -std=gnu99 is > *not* used. > > > For example, if you are building this manually, try setting > ac_cv_prog_cc_c99=no in configure's environment, like so: > > ac_cv_prog_cc_c99=no ./configure > > If you are building this from the port, try adding a line: > > > CONFIGURE_ENV+= ac_cv_prog_cc_c99=no > > > in the port's Makefile. > > From owner-freebsd-stable@FreeBSD.ORG Sat Apr 13 23:03:40 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 AC10629B for ; Sat, 13 Apr 2013 23:03:40 +0000 (UTC) (envelope-from cforgeron@acsi.ca) Received: from AA-Edge2007.acsi.ca (unknown [IPv6:2001:0:4137:9e76:343d:aca:71bb:44fd]) by mx1.freebsd.org (Postfix) with ESMTP id 33CBF171F for ; Sat, 13 Apr 2013 23:03:40 +0000 (UTC) Received: from AA-EX0.acsi.ca (192.168.9.11) by AA-Edge2007.acsi.ca (192.168.9.15) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sat, 13 Apr 2013 20:02:18 -0300 Received: from AA-EX0.acsi.ca ([::1]) by AA-EX0.acsi.ca ([::1]) with mapi id 14.02.0298.004; Sat, 13 Apr 2013 20:02:18 -0300 From: Chris Forgeron To: Jeremy Chadwick Subject: RE: kern/165903: mbuf leak Thread-Topic: kern/165903: mbuf leak Thread-Index: Ac4biy6IuBBGvQzdTV+HyC/2Nu0hHwa1JruAAACBygAAjhhzIA== Date: Sat, 13 Apr 2013 23:02:17 +0000 Message-ID: <46D80686C389884BB0C047851038EC456D8C0EF0@AA-EX0.acsi.ca> References: <46D80686C389884BB0C047851038EC456D8BCEBC@AA-EX0.acsi.ca> <20130410235347.GA38492@icarus.home.lan> <20130411000818.GA38803@icarus.home.lan> In-Reply-To: <20130411000818.GA38803@icarus.home.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.9.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 13 Apr 2013 23:03:40 -0000 To follow-up: I installed 9.1-RELEASE last night, then went and cvsup'ed to the latest th= at RELENG_9 would give me. Everything is completely stock, I have not modified any config files other = than filling out the setup questions (hostname, em0 set to DHCP, added a ba= se user so I can ssh to it) Mu current uname -a is: FreeBSD test 9.1-STABLE FreeBSD 9.1-STABLE #0: Sat = Apr 13 00:29:24 ADT 2013 root@test:/usr/obj/usr/src/sys/GENERIC amd64 I am still having the same mbuf drain problem, that doesn't exist on 9.0-ST= ABLE of July 2012. It's only been 2 hours since my last reboot, and you can already see the dr= ain starting. I expect this box will be unresponsive on the network sometim= e tomorrow. All that has been running is a ssh connection that wasn't moving any traffi= c. Here is a dump of the requested logs. Please note that I give the stats at = boot, then ~2 hours later. Please let me know how I can help this move forward.=20 ------------------------------------------------- After Boot Sat Apr 13 17:41:04 ADT 2013 root@test:/usr/home/aatech # vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 89, 13, 89, 0, 0 UMA Zones: 640, 0, 89, 1, 89, 0, 0 UMA Slabs: 568, 0, 3817, 5, 6208, 0, 0 UMA RCntSlabs: 568, 0, 273, 0, 273, 0, 0 UMA Hash: 256, 0, 3, 12, 4, 0, 0 16 Bucket: 152, 0, 64, 11, 64, 0, 0 32 Bucket: 280, 0, 51, 5, 51, 0, 0 64 Bucket: 536, 0, 34, 1, 34, 62, 0 128 Bucket: 1048, 0, 41, 1, 41, 676, 0 VM OBJECT: 232, 0, 977, 31, 10100, 0, 0 MAP: 232, 0, 7, 25, 7, 0, 0 KMAP ENTRY: 120, 150257, 33, 246, 8450, 0, 0 MAP ENTRY: 120, 0, 753, 115, 23051, 0, 0 fakepg: 120, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 323, 4, 323, 0, 0 16: 16, 0, 2486, 202, 38914, 0, 0 32: 32, 0, 2990, 444, 16915, 0, 0 64: 64, 0, 7243, 261, 37658, 0, 0 128: 128, 0, 8311, 186, 12364, 0, 0 256: 256, 0, 465, 75, 3012, 0, 0 512: 512, 0, 613, 66, 3743, 0, 0 1024: 1024, 0, 34, 162, 4785, 0, 0 2048: 2048, 0, 5129, 141, 5692, 0, 0 4096: 4096, 0, 421, 34, 6083, 0, 0 Files: 80, 0, 78, 102, 3712, 0, 0 rl_entry: 40, 0, 29, 223, 29, 0, 0 TURNSTILE: 136, 0, 115, 45, 115, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1184, 0, 44, 28, 893, 0, 0 THREAD: 1160, 0, 98, 16, 98, 0, 0 SLEEPQUEUE: 80, 0, 115, 30, 115, 0, 0 VMSPACE: 392, 0, 26, 24, 876, 0, 0 cpuset: 72, 0, 51, 49, 51, 0, 0 audit_record: 960, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 288, 224, 1462, 0, 0 mbuf: 256, 0, 2, 266, 380, 0, 0 mbuf_cluster: 2048, 25600, 512, 16, 512, 0, 0 mbuf_jumbo_page: 4096, 12800, 0, 9, 6, 0, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 g_bio: 232, 0, 0, 144, 3498, 0, 0 ttyinq: 160, 0, 180, 60, 765, 0, 0 ttyoutq: 256, 0, 95, 25, 407, 0, 0 ata_request: 328, 0, 0, 48, 86, 0, 0 ata_composite: 336, 0, 0, 0, 0, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 FPU_save_area: 832, 0, 0, 0, 0, 0, 0 VNODE: 504, 0, 490, 30, 516, 0, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 36, 7095, 0, 0 S VFS Cache: 108, 0, 475, 53, 1000, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 0, 0, 0, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 NCLNODE: 568, 0, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 23, 13, 23, 0, 0 pipe: 728, 0, 2, 28, 460, 0, 0 Mountpoints: 824, 0, 2, 6, 2, 0, 0 ksiginfo: 112, 0, 57, 999, 63, 0, 0 itimer: 344, 0, 1, 21, 1, 0, 0 KNOTE: 128, 0, 0, 87, 40, 0, 0 socket: 680, 25602, 23, 13, 283, 0, 0 ipq: 56, 819, 0, 0, 0, 0, 0 udp_inpcb: 392, 25600, 8, 22, 222, 0, 0 udpcb: 16, 25704, 8, 328, 222, 0, 0 tcp_inpcb: 392, 25600, 4, 26, 10, 0, 0 tcpcb: 976, 25600, 4, 8, 10, 0, 0 tcptw: 72, 5150, 0, 0, 0, 0, 0 syncache: 152, 15375, 0, 50, 1, 0, 0 hostcache: 136, 15372, 0, 0, 0, 0, 0 tcpreass: 40, 1680, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1376, 25600, 0, 0, 0, 0, 0 sctp_asoc: 2288, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 216, 3, 0, 0 sctp_raddr: 704, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400008, 0, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0, 0 sctp_stream_msg_out: 112, 400026, 0, 0, 0, 0, 0 sctp_asconf: 40, 400008, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400032, 0, 0, 0, 0, 0 ripcb: 392, 25600, 1, 19, 1, 0, 0 unpcb: 240, 25600, 8, 40, 40, 0, 0 rtentry: 200, 0, 13, 44, 14, 0, 0 selfd: 56, 0, 38, 151, 2435, 0, 0 SWAPMETA: 288, 502372, 0, 0, 0, 0, 0 FFS inode: 168, 0, 453, 53, 477, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 453, 27, 477, 0, 0 root@test:/usr/home/aatech # netstat -Q Configuration: Setting Current Limit Thread count 1 1 Default queue limit 256 10240 Dispatch policy direct n/a Threads bound to CPUs disabled n/a Protocols: Name Proto QLimit Policy Dispatch Flags ip 1 256 flow default --- igmp 2 256 source default --- rtsock 3 256 source default --- arp 7 256 source default --- ether 9 256 source direct --- ip6 10 256 flow default --- Workstreams: WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled 0 0 ip 0 0 6 0 0 0 6 0 0 igmp 0 0 0 0 0 0 0 0 0 rtsock 0 2 0 0 0 16 16 0 0 arp 0 0 1 0 0 0 1 0 0 ether 0 0 7 0 0 0 7 0 0 ip6 0 0 0 0 0 0 0 root@test:/usr/home/aatech # netstat -n -x Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address R-MBUF S-= MBUF R-CLUS S-CLUS R-HIWA S-HIWA R-LOWA S-LOWA=20 R-BCNT S-BCNT R-BMAX S-BMAX rexmt persist keep 2msl delack rcvtime tcp4 0 52 192.168.9.224.22 192.168.9.108.61563 0 = 1 0 0 65700 33580 1 2048=20 0 256 525600 268640 0.37 0.00 7199.90 0.00 0.00 0.10 udp4 0 0 127.0.0.1.123 *.* 0 = 0 0 0 42080 9216 1 2048=20 0 0 336640 73728 udp6 0 0 fe80:4::1.123 *.* 0 = 0 0 0 42080 9216 1 2048=20 0 0 336640 73728 udp6 0 0 ::1.123 *.* 0 = 0 0 0 42080 9216 1 2048=20 0 0 336640 73728 udp4 0 0 192.168.9.224.123 *.* 0 = 0 0 0 42080 9216 1 2048=20 0 0 336640 73728 Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr fffffe00064ab690 stream 0 0 0 fffffe00064ab5a0 0 = 0 fffffe00064ab5a0 stream 0 0 0 fffffe00064ab690 0 = 0 fffffe00064a00f0 stream 0 0 fffffe00063e8bd0 0 0 = 0 /var/run/devd.pipe fffffe00064aa5a0 dgram 0 0 0 fffffe00064aa960 0 = 0 fffffe00064ab0f0 dgram 0 0 0 fffffe00064aa870 0 ff= fffe00064ab1e0 fffffe00064ab1e0 dgram 0 0 0 fffffe00064aa870 0 = 0 fffffe00064aa870 dgram 0 0 fffffe0006531bd0 0 fffffe00064= ab0f0 0 /var/run/logpriv fffffe00064aa960 dgram 0 0 fffffe0006531dc8 0 fffffe00064= aa5a0 0 /var/run/log root@test:/usr/home/aatech # netstat -m 298/737/1035 mbufs in use (current/cache/total) 296/360/656/25600 mbuf clusters in use (current/cache/total/max) 296/344 mbuf+clusters out of packet secondary zone in use (current/cache) 0/9/9/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 666K/940K/1606K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ---------------------------------------------------- After ~2 hours root@test:/usr/home/aatech # date Sat Apr 13 19:32:34 ADT 2013 root@test:/usr/home/aatech # netstat -m 1616/694/2310 mbufs in use (current/cache/total) 1614/322/1936/25600 mbuf clusters in use (current/cache/total/max) 1614/306 mbuf+clusters out of packet secondary zone in use (current/cache) 0/9/9/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 3632K/853K/4485K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines root@test:/usr/home/aatech # vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 89, 13, 89, 0, 0 UMA Zones: 640, 0, 89, 1, 89, 0, 0 UMA Slabs: 568, 0, 3851, 6, 6244, 0, 0 UMA RCntSlabs: 568, 0, 977, 3, 977, 0, 0 UMA Hash: 256, 0, 3, 12, 4, 0, 0 16 Bucket: 152, 0, 65, 10, 65, 0, 0 32 Bucket: 280, 0, 51, 5, 51, 0, 0 64 Bucket: 536, 0, 40, 2, 40, 62, 0 128 Bucket: 1048, 0, 43, 2, 43, 676, 0 VM OBJECT: 232, 0, 1001, 87, 13050, 0, 0 MAP: 232, 0, 7, 25, 7, 0, 0 KMAP ENTRY: 120, 150257, 33, 246, 8454, 0, 0 MAP ENTRY: 120, 0, 753, 146, 29632, 0, 0 fakepg: 120, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 323, 4, 323, 0, 0 16: 16, 0, 2486, 202, 40587, 0, 0 32: 32, 0, 2990, 444, 17187, 0, 0 64: 64, 0, 7260, 300, 41779, 0, 0 128: 128, 0, 8367, 275, 13151, 0, 0 256: 256, 0, 469, 71, 4864, 0, 0 512: 512, 0, 637, 91, 4628, 0, 0 1024: 1024, 0, 34, 162, 5307, 0, 0 2048: 2048, 0, 5129, 141, 5694, 0, 0 4096: 4096, 0, 421, 66, 6369, 0, 0 Files: 80, 0, 78, 147, 5507, 0, 0 rl_entry: 40, 0, 43, 209, 43, 0, 0 TURNSTILE: 136, 0, 133, 27, 133, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1184, 0, 44, 43, 1158, 0, 0 THREAD: 1160, 0, 116, 16, 116, 0, 0 SLEEPQUEUE: 80, 0, 133, 41, 133, 0, 0 VMSPACE: 392, 0, 26, 24, 1076, 0, 0 cpuset: 72, 0, 51, 49, 51, 0, 0 audit_record: 960, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 1622, 298, 31168, 0, 0 mbuf: 256, 0, 2, 388, 5267, 0, 0 mbuf_cluster: 2048, 25600, 1920, 16, 1920, 0, 0 mbuf_jumbo_page: 4096, 12800, 0, 9, 6, 0, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 g_bio: 232, 0, 0, 144, 5175, 0, 0 ttyinq: 160, 0, 180, 60, 765, 0, 0 ttyoutq: 256, 0, 95, 25, 407, 0, 0 ata_request: 328, 0, 0, 48, 2315, 0, 0 ata_composite: 336, 0, 0, 0, 0, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 FPU_save_area: 832, 0, 0, 0, 0, 0, 0 VNODE: 504, 0, 497, 23, 537, 0, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 36, 13140, 0, 0 S VFS Cache: 108, 0, 471, 123, 1525, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 0, 0, 0, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 NCLNODE: 568, 0, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 23, 13, 23, 0, 0 pipe: 728, 0, 2, 28, 534, 0, 0 Mountpoints: 824, 0, 2, 6, 2, 0, 0 ksiginfo: 112, 0, 75, 981, 311, 0, 0 itimer: 344, 0, 1, 21, 1, 0, 0 KNOTE: 128, 0, 0, 87, 40, 0, 0 socket: 680, 25602, 23, 25, 443, 0, 0 ipq: 56, 819, 0, 0, 0, 0, 0 udp_inpcb: 392, 25600, 8, 22, 336, 0, 0 udpcb: 16, 25704, 8, 328, 336, 0, 0 tcp_inpcb: 392, 25600, 4, 26, 14, 0, 0 tcpcb: 976, 25600, 4, 8, 14, 0, 0 tcptw: 72, 5150, 0, 100, 2, 0, 0 syncache: 152, 15375, 0, 50, 3, 0, 0 hostcache: 136, 15372, 0, 0, 0, 0, 0 tcpreass: 40, 1680, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1376, 25600, 0, 0, 0, 0, 0 sctp_asoc: 2288, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 216, 3, 0, 0 sctp_raddr: 704, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400008, 0, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0, 0 sctp_stream_msg_out: 112, 400026, 0, 0, 0, 0, 0 sctp_asconf: 40, 400008, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400032, 0, 0, 0, 0, 0 ripcb: 392, 25600, 1, 19, 1, 0, 0 unpcb: 240, 25600, 8, 40, 82, 0, 0 rtentry: 200, 0, 13, 44, 14, 0, 0 selfd: 56, 0, 42, 147, 64963, 0, 0 SWAPMETA: 288, 502372, 0, 0, 0, 0, 0 FFS inode: 168, 0, 459, 47, 496, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 459, 21, 496, 0, 0 root@test:/usr/home/aatech #=20 root@test:/usr/home/aatech # netstat -Q Configuration: Setting Current Limit Thread count 1 1 Default queue limit 256 10240 Dispatch policy direct n/a Threads bound to CPUs disabled n/a Protocols: Name Proto QLimit Policy Dispatch Flags ip 1 256 flow default --- igmp 2 256 source default --- rtsock 3 256 source default --- arp 7 256 source default --- ether 9 256 source direct --- ip6 10 256 flow default --- Workstreams: WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled 0 0 ip 0 0 166 0 0 0 166 0 0 igmp 0 0 0 0 0 0 0 0 0 rtsock 0 2 0 0 0 16 16 0 0 arp 0 0 63 0 0 0 63 0 0 ether 0 0 229 0 0 0 229 0 0 ip6 0 0 0 0 0 0 0 root@test:/usr/home/aatech #=20 root@test:/usr/home/aatech # netstat -n -x Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address R-MBUF S-= MBUF R-CLUS S-CLUS R-HIWA S-HIWA R-LOWA S-LOWA=20 R-BCNT S-BCNT R-BMAX S-BMAX rexmt persist keep 2msl delack rcvtime tcp4 0 52 192.168.9.224.22 192.168.9.108.61563 0 = 1 0 0 65700 33580 1 2048=20 0 256 525600 268640 0.41 0.00 7199.92 0.00 0.00 0.08 udp4 0 0 127.0.0.1.123 *.* 0 = 0 0 0 42080 9216 1 2048=20 0 0 336640 73728 udp6 0 0 fe80:4::1.123 *.* 0 = 0 0 0 42080 9216 1 2048=20 0 0 336640 73728 udp6 0 0 ::1.123 *.* 0 = 0 0 0 42080 9216 1 2048=20 0 0 336640 73728 udp4 0 0 192.168.9.224.123 *.* 0 = 0 0 0 42080 9216 1 2048=20 0 0 336640 73728 Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr fffffe00064ab690 stream 0 0 0 fffffe00064ab5a0 0 = 0 fffffe00064ab5a0 stream 0 0 0 fffffe00064ab690 0 = 0 fffffe00064a00f0 stream 0 0 fffffe00063e8bd0 0 0 = 0 /var/run/devd.pipe fffffe00064aa5a0 dgram 0 0 0 fffffe00064aa960 0 = 0 fffffe00064ab0f0 dgram 0 0 0 fffffe00064aa870 0 ff= fffe00064ab1e0 fffffe00064ab1e0 dgram 0 0 0 fffffe00064aa870 0 = 0 fffffe00064aa870 dgram 0 0 fffffe0006531bd0 0 fffffe00064= ab0f0 0 /var/run/logpriv fffffe00064aa960 dgram 0 0 fffffe0006531dc8 0 fffffe00064= aa5a0 0 /var/run/log root@test:/usr/home/aatech # From owner-freebsd-stable@FreeBSD.ORG Sat Apr 13 23:50: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 135DE5DE for ; Sat, 13 Apr 2013 23:50:34 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by mx1.freebsd.org (Postfix) with ESMTP id E99E1180D for ; Sat, 13 Apr 2013 23:50:33 +0000 (UTC) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta15.emeryville.ca.mail.comcast.net with comcast id PbDd1l0010cQ2SLAFbqY7E; Sat, 13 Apr 2013 23:50:32 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta10.emeryville.ca.mail.comcast.net with comcast id PbqX1l00c1t3BNj8WbqX3N; Sat, 13 Apr 2013 23:50:32 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8C64273A33; Sat, 13 Apr 2013 16:50:31 -0700 (PDT) Date: Sat, 13 Apr 2013 16:50:31 -0700 From: Jeremy Chadwick To: Chris Forgeron Subject: Re: kern/165903: mbuf leak Message-ID: <20130413235031.GA8212@icarus.home.lan> References: <46D80686C389884BB0C047851038EC456D8BCEBC@AA-EX0.acsi.ca> <20130410235347.GA38492@icarus.home.lan> <20130411000818.GA38803@icarus.home.lan> <46D80686C389884BB0C047851038EC456D8C0EF0@AA-EX0.acsi.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46D80686C389884BB0C047851038EC456D8C0EF0@AA-EX0.acsi.ca> 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=1365897032; bh=6W4AaPhYpMDKa12/SHn2zr++AuWbqHtf4gVia/Q24nw=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=LCx7ka+iA3PobdBJiNvnaNlh7bK3Jntb27VvUHgWNnXip6WwgzNiebkJwFP+bAPbg oi5oxFtfRm5vITrVPAn6gCocPqL7/IaYtn4y/IX0AM4shXwOHvZYhTPIkutcu85EQK E0JL85otVZ2e0SNWymX3SR84xXZE+PhUr7vmnSsui0ygwQ+sdpalqRdr2pLaHEmpf4 su8OTjiWiAsZMTT1EZe9DSEl4VbZXiUi9x9GxnIWZkEpEsuKvEB/ehjG4W5iYlrTQO wx+jpI3ld8Sk9vndZIH/GcSdxboPoCB6m9D3r8b5sEy3Ihu9ShtWzAvT0m+eS7SNwm iDHTA45PHSWCw== Cc: "freebsd-stable@freebsd.org" , Jack Vogel , 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: Sat, 13 Apr 2013 23:50:34 -0000 On Sat, Apr 13, 2013 at 11:02:17PM +0000, Chris Forgeron wrote: > To follow-up: > > I installed 9.1-RELEASE last night, then went and cvsup'ed to the latest that RELENG_9 would give me. > > Everything is completely stock, I have not modified any config files other than filling out the setup questions (hostname, em0 set to DHCP, added a base user so I can ssh to it) > > Mu current uname -a is: FreeBSD test 9.1-STABLE FreeBSD 9.1-STABLE #0: Sat Apr 13 00:29:24 ADT 2013 root@test:/usr/obj/usr/src/sys/GENERIC amd64 > > I am still having the same mbuf drain problem, that doesn't exist on 9.0-STABLE of July 2012. > > It's only been 2 hours since my last reboot, and you can already see the drain starting. I expect this box will be unresponsive on the network sometime tomorrow. > > All that has been running is a ssh connection that wasn't moving any traffic. > > > Here is a dump of the requested logs. Please note that I give the stats at boot, then ~2 hours later. > > Please let me know how I can help this move forward. > > ------------------------------------------------- > After Boot > > > Sat Apr 13 17:41:04 ADT 2013 > root@test:/usr/home/aatech # vmstat -z > ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > > UMA Kegs: 208, 0, 89, 13, 89, 0, 0 > UMA Zones: 640, 0, 89, 1, 89, 0, 0 > UMA Slabs: 568, 0, 3817, 5, 6208, 0, 0 > UMA RCntSlabs: 568, 0, 273, 0, 273, 0, 0 > UMA Hash: 256, 0, 3, 12, 4, 0, 0 > 16 Bucket: 152, 0, 64, 11, 64, 0, 0 > 32 Bucket: 280, 0, 51, 5, 51, 0, 0 > 64 Bucket: 536, 0, 34, 1, 34, 62, 0 > 128 Bucket: 1048, 0, 41, 1, 41, 676, 0 > VM OBJECT: 232, 0, 977, 31, 10100, 0, 0 > MAP: 232, 0, 7, 25, 7, 0, 0 > KMAP ENTRY: 120, 150257, 33, 246, 8450, 0, 0 > MAP ENTRY: 120, 0, 753, 115, 23051, 0, 0 > fakepg: 120, 0, 0, 0, 0, 0, 0 > mt_zone: 4112, 0, 323, 4, 323, 0, 0 > 16: 16, 0, 2486, 202, 38914, 0, 0 > 32: 32, 0, 2990, 444, 16915, 0, 0 > 64: 64, 0, 7243, 261, 37658, 0, 0 > 128: 128, 0, 8311, 186, 12364, 0, 0 > 256: 256, 0, 465, 75, 3012, 0, 0 > 512: 512, 0, 613, 66, 3743, 0, 0 > 1024: 1024, 0, 34, 162, 4785, 0, 0 > 2048: 2048, 0, 5129, 141, 5692, 0, 0 > 4096: 4096, 0, 421, 34, 6083, 0, 0 > Files: 80, 0, 78, 102, 3712, 0, 0 > rl_entry: 40, 0, 29, 223, 29, 0, 0 > TURNSTILE: 136, 0, 115, 45, 115, 0, 0 > umtx pi: 96, 0, 0, 0, 0, 0, 0 > MAC labels: 40, 0, 0, 0, 0, 0, 0 > PROC: 1184, 0, 44, 28, 893, 0, 0 > THREAD: 1160, 0, 98, 16, 98, 0, 0 > SLEEPQUEUE: 80, 0, 115, 30, 115, 0, 0 > VMSPACE: 392, 0, 26, 24, 876, 0, 0 > cpuset: 72, 0, 51, 49, 51, 0, 0 > audit_record: 960, 0, 0, 0, 0, 0, 0 > mbuf_packet: 256, 0, 288, 224, 1462, 0, 0 > mbuf: 256, 0, 2, 266, 380, 0, 0 > mbuf_cluster: 2048, 25600, 512, 16, 512, 0, 0 > mbuf_jumbo_page: 4096, 12800, 0, 9, 6, 0, 0 > mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0, 0 > mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0, 0 > mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 > g_bio: 232, 0, 0, 144, 3498, 0, 0 > ttyinq: 160, 0, 180, 60, 765, 0, 0 > ttyoutq: 256, 0, 95, 25, 407, 0, 0 > ata_request: 328, 0, 0, 48, 86, 0, 0 > ata_composite: 336, 0, 0, 0, 0, 0, 0 > vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 > FPU_save_area: 832, 0, 0, 0, 0, 0, 0 > VNODE: 504, 0, 490, 30, 516, 0, 0 > VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 > NAMEI: 1024, 0, 0, 36, 7095, 0, 0 > S VFS Cache: 108, 0, 475, 53, 1000, 0, 0 > STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 > L VFS Cache: 328, 0, 0, 0, 0, 0, 0 > LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 > NCLNODE: 568, 0, 0, 0, 0, 0, 0 > DIRHASH: 1024, 0, 23, 13, 23, 0, 0 > pipe: 728, 0, 2, 28, 460, 0, 0 > Mountpoints: 824, 0, 2, 6, 2, 0, 0 > ksiginfo: 112, 0, 57, 999, 63, 0, 0 > itimer: 344, 0, 1, 21, 1, 0, 0 > KNOTE: 128, 0, 0, 87, 40, 0, 0 > socket: 680, 25602, 23, 13, 283, 0, 0 > ipq: 56, 819, 0, 0, 0, 0, 0 > udp_inpcb: 392, 25600, 8, 22, 222, 0, 0 > udpcb: 16, 25704, 8, 328, 222, 0, 0 > tcp_inpcb: 392, 25600, 4, 26, 10, 0, 0 > tcpcb: 976, 25600, 4, 8, 10, 0, 0 > tcptw: 72, 5150, 0, 0, 0, 0, 0 > syncache: 152, 15375, 0, 50, 1, 0, 0 > hostcache: 136, 15372, 0, 0, 0, 0, 0 > tcpreass: 40, 1680, 0, 0, 0, 0, 0 > sackhole: 32, 0, 0, 0, 0, 0, 0 > sctp_ep: 1376, 25600, 0, 0, 0, 0, 0 > sctp_asoc: 2288, 40000, 0, 0, 0, 0, 0 > sctp_laddr: 48, 80064, 0, 216, 3, 0, 0 > sctp_raddr: 704, 80000, 0, 0, 0, 0, 0 > sctp_chunk: 136, 400008, 0, 0, 0, 0, 0 > sctp_readq: 104, 400032, 0, 0, 0, 0, 0 > sctp_stream_msg_out: 112, 400026, 0, 0, 0, 0, 0 > sctp_asconf: 40, 400008, 0, 0, 0, 0, 0 > sctp_asconf_ack: 48, 400032, 0, 0, 0, 0, 0 > ripcb: 392, 25600, 1, 19, 1, 0, 0 > unpcb: 240, 25600, 8, 40, 40, 0, 0 > rtentry: 200, 0, 13, 44, 14, 0, 0 > selfd: 56, 0, 38, 151, 2435, 0, 0 > SWAPMETA: 288, 502372, 0, 0, 0, 0, 0 > FFS inode: 168, 0, 453, 53, 477, 0, 0 > FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 > FFS2 dinode: 256, 0, 453, 27, 477, 0, 0 > > root@test:/usr/home/aatech # netstat -Q > Configuration: > Setting Current Limit > Thread count 1 1 > Default queue limit 256 10240 > Dispatch policy direct n/a > Threads bound to CPUs disabled n/a > > Protocols: > Name Proto QLimit Policy Dispatch Flags > ip 1 256 flow default --- > igmp 2 256 source default --- > rtsock 3 256 source default --- > arp 7 256 source default --- > ether 9 256 source direct --- > ip6 10 256 flow default --- > > Workstreams: > WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled > 0 0 ip 0 0 6 0 0 0 6 > 0 0 igmp 0 0 0 0 0 0 0 > 0 0 rtsock 0 2 0 0 0 16 16 > 0 0 arp 0 0 1 0 0 0 1 > 0 0 ether 0 0 7 0 0 0 7 > 0 0 ip6 0 0 0 0 0 0 0 > root@test:/usr/home/aatech # netstat -n -x > Active Internet connections > Proto Recv-Q Send-Q Local Address Foreign Address R-MBUF S-MBUF R-CLUS S-CLUS R-HIWA S-HIWA R-LOWA S-LOWA > > R-BCNT S-BCNT R-BMAX S-BMAX rexmt persist keep 2msl delack rcvtime > tcp4 0 52 192.168.9.224.22 192.168.9.108.61563 0 1 0 0 65700 33580 1 2048 > > 0 256 525600 268640 0.37 0.00 7199.90 0.00 0.00 0.10 > udp4 0 0 127.0.0.1.123 *.* 0 0 0 0 42080 9216 1 2048 > > 0 0 336640 73728 > udp6 0 0 fe80:4::1.123 *.* 0 0 0 0 42080 9216 1 2048 > > 0 0 336640 73728 > udp6 0 0 ::1.123 *.* 0 0 0 0 42080 9216 1 2048 > > 0 0 336640 73728 > udp4 0 0 192.168.9.224.123 *.* 0 0 0 0 42080 9216 1 2048 > > 0 0 336640 73728 > Active UNIX domain sockets > Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr > fffffe00064ab690 stream 0 0 0 fffffe00064ab5a0 0 0 > fffffe00064ab5a0 stream 0 0 0 fffffe00064ab690 0 0 > fffffe00064a00f0 stream 0 0 fffffe00063e8bd0 0 0 0 /var/run/devd.pipe > fffffe00064aa5a0 dgram 0 0 0 fffffe00064aa960 0 0 > fffffe00064ab0f0 dgram 0 0 0 fffffe00064aa870 0 fffffe00064ab1e0 > fffffe00064ab1e0 dgram 0 0 0 fffffe00064aa870 0 0 > fffffe00064aa870 dgram 0 0 fffffe0006531bd0 0 fffffe00064ab0f0 0 /var/run/logpriv > fffffe00064aa960 dgram 0 0 fffffe0006531dc8 0 fffffe00064aa5a0 0 /var/run/log > root@test:/usr/home/aatech # netstat -m > 298/737/1035 mbufs in use (current/cache/total) > 296/360/656/25600 mbuf clusters in use (current/cache/total/max) > 296/344 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/9/9/12800 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 666K/940K/1606K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > > ---------------------------------------------------- > After ~2 hours > > root@test:/usr/home/aatech # date > Sat Apr 13 19:32:34 ADT 2013 > root@test:/usr/home/aatech # netstat -m > 1616/694/2310 mbufs in use (current/cache/total) > 1614/322/1936/25600 mbuf clusters in use (current/cache/total/max) > 1614/306 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/9/9/12800 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 3632K/853K/4485K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > root@test:/usr/home/aatech # vmstat -z > ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > > UMA Kegs: 208, 0, 89, 13, 89, 0, 0 > UMA Zones: 640, 0, 89, 1, 89, 0, 0 > UMA Slabs: 568, 0, 3851, 6, 6244, 0, 0 > UMA RCntSlabs: 568, 0, 977, 3, 977, 0, 0 > UMA Hash: 256, 0, 3, 12, 4, 0, 0 > 16 Bucket: 152, 0, 65, 10, 65, 0, 0 > 32 Bucket: 280, 0, 51, 5, 51, 0, 0 > 64 Bucket: 536, 0, 40, 2, 40, 62, 0 > 128 Bucket: 1048, 0, 43, 2, 43, 676, 0 > VM OBJECT: 232, 0, 1001, 87, 13050, 0, 0 > MAP: 232, 0, 7, 25, 7, 0, 0 > KMAP ENTRY: 120, 150257, 33, 246, 8454, 0, 0 > MAP ENTRY: 120, 0, 753, 146, 29632, 0, 0 > fakepg: 120, 0, 0, 0, 0, 0, 0 > mt_zone: 4112, 0, 323, 4, 323, 0, 0 > 16: 16, 0, 2486, 202, 40587, 0, 0 > 32: 32, 0, 2990, 444, 17187, 0, 0 > 64: 64, 0, 7260, 300, 41779, 0, 0 > 128: 128, 0, 8367, 275, 13151, 0, 0 > 256: 256, 0, 469, 71, 4864, 0, 0 > 512: 512, 0, 637, 91, 4628, 0, 0 > 1024: 1024, 0, 34, 162, 5307, 0, 0 > 2048: 2048, 0, 5129, 141, 5694, 0, 0 > 4096: 4096, 0, 421, 66, 6369, 0, 0 > Files: 80, 0, 78, 147, 5507, 0, 0 > rl_entry: 40, 0, 43, 209, 43, 0, 0 > TURNSTILE: 136, 0, 133, 27, 133, 0, 0 > umtx pi: 96, 0, 0, 0, 0, 0, 0 > MAC labels: 40, 0, 0, 0, 0, 0, 0 > PROC: 1184, 0, 44, 43, 1158, 0, 0 > THREAD: 1160, 0, 116, 16, 116, 0, 0 > SLEEPQUEUE: 80, 0, 133, 41, 133, 0, 0 > VMSPACE: 392, 0, 26, 24, 1076, 0, 0 > cpuset: 72, 0, 51, 49, 51, 0, 0 > audit_record: 960, 0, 0, 0, 0, 0, 0 > mbuf_packet: 256, 0, 1622, 298, 31168, 0, 0 > mbuf: 256, 0, 2, 388, 5267, 0, 0 > mbuf_cluster: 2048, 25600, 1920, 16, 1920, 0, 0 > mbuf_jumbo_page: 4096, 12800, 0, 9, 6, 0, 0 > mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0, 0 > mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0, 0 > mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 > g_bio: 232, 0, 0, 144, 5175, 0, 0 > ttyinq: 160, 0, 180, 60, 765, 0, 0 > ttyoutq: 256, 0, 95, 25, 407, 0, 0 > ata_request: 328, 0, 0, 48, 2315, 0, 0 > ata_composite: 336, 0, 0, 0, 0, 0, 0 > vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 > FPU_save_area: 832, 0, 0, 0, 0, 0, 0 > VNODE: 504, 0, 497, 23, 537, 0, 0 > VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 > NAMEI: 1024, 0, 0, 36, 13140, 0, 0 > S VFS Cache: 108, 0, 471, 123, 1525, 0, 0 > STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 > L VFS Cache: 328, 0, 0, 0, 0, 0, 0 > LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 > NCLNODE: 568, 0, 0, 0, 0, 0, 0 > DIRHASH: 1024, 0, 23, 13, 23, 0, 0 > pipe: 728, 0, 2, 28, 534, 0, 0 > Mountpoints: 824, 0, 2, 6, 2, 0, 0 > ksiginfo: 112, 0, 75, 981, 311, 0, 0 > itimer: 344, 0, 1, 21, 1, 0, 0 > KNOTE: 128, 0, 0, 87, 40, 0, 0 > socket: 680, 25602, 23, 25, 443, 0, 0 > ipq: 56, 819, 0, 0, 0, 0, 0 > udp_inpcb: 392, 25600, 8, 22, 336, 0, 0 > udpcb: 16, 25704, 8, 328, 336, 0, 0 > tcp_inpcb: 392, 25600, 4, 26, 14, 0, 0 > tcpcb: 976, 25600, 4, 8, 14, 0, 0 > tcptw: 72, 5150, 0, 100, 2, 0, 0 > syncache: 152, 15375, 0, 50, 3, 0, 0 > hostcache: 136, 15372, 0, 0, 0, 0, 0 > tcpreass: 40, 1680, 0, 0, 0, 0, 0 > sackhole: 32, 0, 0, 0, 0, 0, 0 > sctp_ep: 1376, 25600, 0, 0, 0, 0, 0 > sctp_asoc: 2288, 40000, 0, 0, 0, 0, 0 > sctp_laddr: 48, 80064, 0, 216, 3, 0, 0 > sctp_raddr: 704, 80000, 0, 0, 0, 0, 0 > sctp_chunk: 136, 400008, 0, 0, 0, 0, 0 > sctp_readq: 104, 400032, 0, 0, 0, 0, 0 > sctp_stream_msg_out: 112, 400026, 0, 0, 0, 0, 0 > sctp_asconf: 40, 400008, 0, 0, 0, 0, 0 > sctp_asconf_ack: 48, 400032, 0, 0, 0, 0, 0 > ripcb: 392, 25600, 1, 19, 1, 0, 0 > unpcb: 240, 25600, 8, 40, 82, 0, 0 > rtentry: 200, 0, 13, 44, 14, 0, 0 > selfd: 56, 0, 42, 147, 64963, 0, 0 > SWAPMETA: 288, 502372, 0, 0, 0, 0, 0 > FFS inode: 168, 0, 459, 47, 496, 0, 0 > FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 > FFS2 dinode: 256, 0, 459, 21, 496, 0, 0 > > root@test:/usr/home/aatech # > root@test:/usr/home/aatech # netstat -Q > Configuration: > Setting Current Limit > Thread count 1 1 > Default queue limit 256 10240 > Dispatch policy direct n/a > Threads bound to CPUs disabled n/a > > Protocols: > Name Proto QLimit Policy Dispatch Flags > ip 1 256 flow default --- > igmp 2 256 source default --- > rtsock 3 256 source default --- > arp 7 256 source default --- > ether 9 256 source direct --- > ip6 10 256 flow default --- > > Workstreams: > WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled > 0 0 ip 0 0 166 0 0 0 166 > 0 0 igmp 0 0 0 0 0 0 0 > 0 0 rtsock 0 2 0 0 0 16 16 > 0 0 arp 0 0 63 0 0 0 63 > 0 0 ether 0 0 229 0 0 0 229 > 0 0 ip6 0 0 0 0 0 0 0 > root@test:/usr/home/aatech # > > root@test:/usr/home/aatech # netstat -n -x > Active Internet connections > Proto Recv-Q Send-Q Local Address Foreign Address R-MBUF S-MBUF R-CLUS S-CLUS R-HIWA S-HIWA R-LOWA S-LOWA > > R-BCNT S-BCNT R-BMAX S-BMAX rexmt persist keep 2msl delack rcvtime > tcp4 0 52 192.168.9.224.22 192.168.9.108.61563 0 1 0 0 65700 33580 1 2048 > > 0 256 525600 268640 0.41 0.00 7199.92 0.00 0.00 0.08 > udp4 0 0 127.0.0.1.123 *.* 0 0 0 0 42080 9216 1 2048 > > 0 0 336640 73728 > udp6 0 0 fe80:4::1.123 *.* 0 0 0 0 42080 9216 1 2048 > > 0 0 336640 73728 > udp6 0 0 ::1.123 *.* 0 0 0 0 42080 9216 1 2048 > > 0 0 336640 73728 > udp4 0 0 192.168.9.224.123 *.* 0 0 0 0 42080 9216 1 2048 > > 0 0 336640 73728 > Active UNIX domain sockets > Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr > fffffe00064ab690 stream 0 0 0 fffffe00064ab5a0 0 0 > fffffe00064ab5a0 stream 0 0 0 fffffe00064ab690 0 0 > fffffe00064a00f0 stream 0 0 fffffe00063e8bd0 0 0 0 /var/run/devd.pipe > fffffe00064aa5a0 dgram 0 0 0 fffffe00064aa960 0 0 > fffffe00064ab0f0 dgram 0 0 0 fffffe00064aa870 0 fffffe00064ab1e0 > fffffe00064ab1e0 dgram 0 0 0 fffffe00064aa870 0 0 > fffffe00064aa870 dgram 0 0 fffffe0006531bd0 0 fffffe00064ab0f0 0 /var/run/logpriv > fffffe00064aa960 dgram 0 0 fffffe0006531dc8 0 fffffe00064aa5a0 0 /var/run/log > root@test:/usr/home/aatech # Thanks for the info Chris, greatly appreciated. It looks like you're still using csup/cvsup to pull down your src bits, rather than svn. I was under the impression the CVS stuff had been turned off, or at least deprecated to the point where SVN->CVS backporting had been disabled for quite some time (since November) -- so you may still be running off of "older" drivers. Driver commits are here: http://svnweb.freebsd.org/base/stable/9/sys/dev/e1000/ Could you also provide output from these commands (in the state of having high mbuf counts): * dmesg * pciconf -lvbc (only need the lines relevant to em0) * sysctl -a dev.em.0 I've CC'd Jack Vogel of Intel (driver maintainer) and John Baldwin for possible assistance in tracking this down further. Finally, just for comparison, here are numbers from two systems I have access to -- one is bare metal, the other is a VPS running under QEMU. The former has an uptime of 8 days, the latter 2 days (I was doing world updates at that time). Bare metal box uses an 82573E (card=0x108c15d9 chip=0x108c8086 rev=0x03): 1024/1796/2820 mbufs in use (current/cache/total) 1023/1383/2406/25600 mbuf clusters in use (current/cache/total/max) 1023/769 mbuf+clusters out of packet secondary zone in use (current/cache) 0/789/789/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 2302K/6371K/8673K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP mbuf_packet: 256, 0, 1023, 769,18120075, 0, 0 mbuf: 256, 0, 1, 1027,63685407, 0, 0 mbuf_cluster: 2048, 25600, 1792, 614, 9344, 0, 0 mbuf_jumbo_page: 4096, 12800, 0, 789,12882701, 0, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 QEMU system emulates an 82540EM (card=0x11001af4 chip=0x100e8086 rev=0x03): ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP mbuf_packet: 256, 0, 256, 128, 2804208, 0, 0 mbuf: 256, 0, 2, 334,10103829, 0, 0 mbuf_cluster: 2048, 25600, 384, 6, 384, 0, 0 mbuf_jumbo_page: 4096, 12800, 0, 24, 4632, 0, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 168, 11688, 0, 0 258/462/720 mbufs in use (current/cache/total) 256/134/390/25600 mbuf clusters in use (current/cache/total/max) 256/128 mbuf+clusters out of packet secondary zone in use (current/cache) 0/24/24/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 576K/479K/1056K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 197 requests for I/O initiated by sendfile 0 calls to protocol drain routines -- | 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 |