From owner-freebsd-stable@FreeBSD.ORG Sun Aug 25 03:53:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 403EC6BC for ; Sun, 25 Aug 2013 03:53:39 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) Received: from nm22-vm5.access.bullet.mail.bf1.yahoo.com (nm22-vm5.access.bullet.mail.bf1.yahoo.com [216.109.115.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CA7A62540 for ; Sun, 25 Aug 2013 03:53:38 +0000 (UTC) Received: from [66.196.81.158] by nm22.access.bullet.mail.bf1.yahoo.com with NNFMP; 25 Aug 2013 03:53:31 -0000 Received: from [98.139.221.52] by tm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 25 Aug 2013 03:53:31 -0000 Received: from [127.0.0.1] by smtp105.sbc.mail.bf1.yahoo.com with NNFMP; 25 Aug 2013 03:53:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1377402811; bh=ZQFGhxJsNU5xxyxa9jM+ug1uBfzoJWoUUCkRKEzkAWA=; h=X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:To:CC:Subject; b=17B2nINjh8ZLsSCUuo/6C4N21H5IMZCZjsiutI0iBMz5/rBuHcjoLXxo0bxemIRiYwvdROMHAXeTPX3kpVFvSm/ojMBRzVANkq5/auPWfSZYd4iDD5A4JC6uUX08nJicmTqjNAnwkQIX/JGcDCytLzTgiM1Us8gFRKLbG3AHDFw= X-Yahoo-Newman-Id: 339077.27046.bm@smtp105.sbc.mail.bf1.yahoo.com Message-ID: <339077.27046.bm@smtp105.sbc.mail.bf1.yahoo.com> Date: Sat, 24 Aug 2013 20:53:31 -0700 (PDT) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: QzcfOvwVM1kCTYBIOcsNIGHBv1yvBKJk81EUbUHK2xxc0wX PQ1yne77ZGnESwed.60haJuryhkw2aXopjjhdrmrS8ro0hoGuAZnOwbf8I5W whY2erpI3a6FLhV7vcej.ygAAH9AtKq7hHK_xhFx3stNF0UDHWfnJvs7SB69 ryDOfh.HMQdhppnoxBrR3zMI2LpuG.H9KT7Yyty77n9hSkNRksC5o7OXZ9Qn 58P3QrP5ydIhL94O4yU9Nlh9AhcUXr2ZhuDFFwK3pm4UM4EM2OY6Jc8gARZS tUkIM4VnrF8mZlTjSTLbe7XqG_vyvbRqejPXgYfzxRBWsZ4OrFkVdQDiU8HA GDaB6y6vAGesGJFj9hhEkJ2QrrsM_7CStAwdh_fqb2xtpY1m8tG5fcVauOA8 jhH9HvT18yJAw_nsmQkxzKmabJd53hBnZYNsO697mA3O.vLi73LY0TsSRm3r mh_EVnPUs0T6NzuTX8GNrHIO6v7PXF_9GdBB0RgFcAN40_8ZTNlW539KtZPQ yEMyDR35rfRzpX9tawEdeDlBXou_0Z8ctJLyL5APrWGGIASymrkloZcga5Oe bqWobH0pF X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- X-Rocket-Received: from localhost (mueller6724@74.130.200.176 with plain) by smtp105.sbc.mail.bf1.yahoo.com with SMTP; 24 Aug 2013 20:53:31 -0700 PDT From: "Thomas Mueller" To: freebsd-stable@freebsd.org Subject: Re: Change in loader or kernel: won't boot with kfreebsd in grub2 Cc: "Andrey V. Elsukov" , Juergen Lock 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, 25 Aug 2013 03:53:39 -0000 Some updates: I could see what happens if I try to boot the FreeBSD boot partition on the hard drive using the Super Grub Disk with chainloader. If that works, it would boot FreeBSD 9.0-BETA1, but I would see if it works. That failed (invalid signature). I could also try kfreebsd /boot/kernel/kernel That failed to boot the proper partition, went to the debugger (db>), whereupon all I could type was "reboot". Now can I safely install boot into the partition to be booted, as I did with NetBSD on USB stick? gpart -p /boot/boot -i 3 That would be for /dev/ada0p3, but I am afraid of damaging something. Tom From owner-freebsd-stable@FreeBSD.ORG Sun Aug 25 07:16: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2BD2353B for ; Sun, 25 Aug 2013 07:16:40 +0000 (UTC) (envelope-from prvs=0949e860e2=michael@esosoft.com) Received: from eagle.esosoft.net (eagle.esosoft.net [66.241.144.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 156992D08 for ; Sun, 25 Aug 2013 07:16:39 +0000 (UTC) Received: from [74.100.23.197] (port=41089 helo=michaelimac.castillodelsol.com) by eagle.esosoft.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VDUAs-0005uJ-BD; Sat, 24 Aug 2013 23:51:46 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: NFS deadlock on 9.2-Beta1 From: Michael Tratz In-Reply-To: <461392652.9990692.1376602743970.JavaMail.root@uoguelph.ca> Date: Sat, 24 Aug 2013 23:51:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <40674FAC-33E6-4994-819E-6B8318B9DDB3@esosoft.com> References: <461392652.9990692.1376602743970.JavaMail.root@uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1508) 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, 25 Aug 2013 07:16:40 -0000 On Aug 15, 2013, at 2:39 PM, Rick Macklem wrote: > Michael Tratz wrote: >>=20 >> On Jul 27, 2013, at 11:25 PM, Konstantin Belousov >> wrote: >>=20 >>> On Sat, Jul 27, 2013 at 03:13:05PM -0700, Michael Tratz wrote: >>>> Let's assume the pid which started the deadlock is 14001 (it will >>>> be a different pid when we get the results, because the machine >>>> has been restarted) >>>>=20 >>>> I type: >>>>=20 >>>> show proc 14001 >>>>=20 >>>> I get the thread numbers from that output and type: >>>>=20 >>>> show thread xxxxx >>>>=20 >>>> for each one. >>>>=20 >>>> And a trace for each thread with the command? >>>>=20 >>>> tr xxxx >>>>=20 >>>> Anything else I should try to get or do? Or is that not the data >>>> at all you are looking for? >>>>=20 >>> Yes, everything else which is listed in the 'debugging deadlocks' >>> page >>> must be provided, otherwise the deadlock cannot be tracked. >>>=20 >>> The investigator should be able to see the whole deadlock chain >>> (loop) >>> to make any useful advance. >>=20 >> Ok, I have made some excellent progress in debugging the NFS >> deadlock. >>=20 >> Rick! You are genius. :-) You found the right commit r250907 (dated >> May 22) is the definitely the problem. >>=20 >> Here is how I did the testing: One machine received a kernel before >> r250907, the second machine received a kernel after r250907. Sure >> enough within a few hours the machine with r250907 went into the >> usual deadlock state. The machine without that commit kept on >> working fine. Then I went back to the latest revision (r253726), but >> leaving r250907 out. The machines have been running happy and rock >> solid without any deadlocks. I have expanded the testing to 3 >> machines now and no reports of any issues. >>=20 >> I guess now Konstantin has to figure out why that commit is causing >> the deadlock. Lovely! :-) I will get that information as soon as >> possible. I'm a little behind with normal work load, but I expect to >> have the data by Tuesday evening or Wednesday. >>=20 > Have you been able to pass the debugging info on to Kostik? >=20 > It would be really nice to get this fixed for FreeBSD9.2. >=20 > Thanks for your help with this, rick Sorry Rick, I wasn't able to get you guys that info quickly enough. I = thought I would have enough time, before my own wedding and honeymoon = came along, but everything went a little crazy and stressful. I didn't = think it would be this nuts. :-) I'm caught up with everything and from what I can see from the = discussions is that we know now what the problem is. I can report that the machines which I have had without r250907 have = been running without any problems for 27+ days. If you need me to test any new patches, please let me know. If I should = test with the partial merge of r253927 I'll be happy to do so. Thanks, Michael From owner-freebsd-stable@FreeBSD.ORG Sun Aug 25 11:42: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5B06120F for ; Sun, 25 Aug 2013 11:42:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B61A2943 for ; Sun, 25 Aug 2013 11:42:34 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id l13so1033440qcy.39 for ; Sun, 25 Aug 2013 04:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1mpSOAX/KIfJsKHPq6ripGmMWnTVHc2UV1yF4MHFqjA=; b=QKYgL0RPtRKffovBWNHy58wKBZrnh+BrRW5EYLBAtwhdkHMjkCi7vu0Rhn1HovGQ42 pQc8Qbq3bVjGjxrEwRc7/pNUX88lWGWYx/39h46Ssnzhtes0GTwPW5piYfoC2n/z8llK XEJmNtsX05ciFGrKKHNx1TWa3HqDgJNxDUCDipNHNypZA6CwCjmdKgMA2MScGWLyOf4E 8hQJG801gRtH5BRSCpPQTS96PZeA4+lpnj1VTma8Zer0UUDX4AVvW2WjvLiEjVub+IXQ O7XSI+bEL+R30vUznPzclneAZkmZIEZbp6L5YFCmSmK/2NAHUta8NmfTUqo1VLCY1nIm 3iwQ== MIME-Version: 1.0 X-Received: by 10.224.68.4 with SMTP id t4mr9695122qai.67.1377430953195; Sun, 25 Aug 2013 04:42:33 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Sun, 25 Aug 2013 04:42:33 -0700 (PDT) In-Reply-To: <40674FAC-33E6-4994-819E-6B8318B9DDB3@esosoft.com> References: <461392652.9990692.1376602743970.JavaMail.root@uoguelph.ca> <40674FAC-33E6-4994-819E-6B8318B9DDB3@esosoft.com> Date: Sun, 25 Aug 2013 04:42:33 -0700 X-Google-Sender-Auth: Y7WiYhYdoiljwMTwiwLWf87ZFhY Message-ID: Subject: Re: NFS deadlock on 9.2-Beta1 From: Adrian Chadd To: Michael Tratz Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Rick Macklem , FreeBSD Stable Mailing List 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, 25 Aug 2013 11:42:34 -0000 Hi, Does -HEAD have this same problem? If so, we should likely just revert the patch entirely from -HEAD and -9 until it's resolved. -adrian On 24 August 2013 23:51, Michael Tratz wrote: > > On Aug 15, 2013, at 2:39 PM, Rick Macklem wrote: > > > Michael Tratz wrote: > >> > >> On Jul 27, 2013, at 11:25 PM, Konstantin Belousov > >> wrote: > >> > >>> On Sat, Jul 27, 2013 at 03:13:05PM -0700, Michael Tratz wrote: > >>>> Let's assume the pid which started the deadlock is 14001 (it will > >>>> be a different pid when we get the results, because the machine > >>>> has been restarted) > >>>> > >>>> I type: > >>>> > >>>> show proc 14001 > >>>> > >>>> I get the thread numbers from that output and type: > >>>> > >>>> show thread xxxxx > >>>> > >>>> for each one. > >>>> > >>>> And a trace for each thread with the command? > >>>> > >>>> tr xxxx > >>>> > >>>> Anything else I should try to get or do? Or is that not the data > >>>> at all you are looking for? > >>>> > >>> Yes, everything else which is listed in the 'debugging deadlocks' > >>> page > >>> must be provided, otherwise the deadlock cannot be tracked. > >>> > >>> The investigator should be able to see the whole deadlock chain > >>> (loop) > >>> to make any useful advance. > >> > >> Ok, I have made some excellent progress in debugging the NFS > >> deadlock. > >> > >> Rick! You are genius. :-) You found the right commit r250907 (dated > >> May 22) is the definitely the problem. > >> > >> Here is how I did the testing: One machine received a kernel before > >> r250907, the second machine received a kernel after r250907. Sure > >> enough within a few hours the machine with r250907 went into the > >> usual deadlock state. The machine without that commit kept on > >> working fine. Then I went back to the latest revision (r253726), but > >> leaving r250907 out. The machines have been running happy and rock > >> solid without any deadlocks. I have expanded the testing to 3 > >> machines now and no reports of any issues. > >> > >> I guess now Konstantin has to figure out why that commit is causing > >> the deadlock. Lovely! :-) I will get that information as soon as > >> possible. I'm a little behind with normal work load, but I expect to > >> have the data by Tuesday evening or Wednesday. > >> > > Have you been able to pass the debugging info on to Kostik? > > > > It would be really nice to get this fixed for FreeBSD9.2. > > > > Thanks for your help with this, rick > > Sorry Rick, I wasn't able to get you guys that info quickly enough. I > thought I would have enough time, before my own wedding and honeymoon came > along, but everything went a little crazy and stressful. I didn't think it > would be this nuts. :-) > > I'm caught up with everything and from what I can see from the discussions > is that we know now what the problem is. > > I can report that the machines which I have had without r250907 have been > running without any problems for 27+ days. > > If you need me to test any new patches, please let me know. If I should > test with the partial merge of r253927 I'll be happy to do so. > > Thanks, > > Michael > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sun Aug 25 12:36:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 303B9D0F for ; Sun, 25 Aug 2013 12:36:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id EB2852B81 for ; Sun, 25 Aug 2013 12:36:54 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAAj6GVKDaFve/2dsb2JhbABZhA2DJ7xugTB0giQBAQQBI1YFFhgCAg0ZAiM2BhOHbwMJBqRWh3QNiWqBKYxWgkU0B4JogTEDlgWOHoUsgzoggW4 X-IronPort-AV: E=Sophos;i="4.89,951,1367985600"; d="scan'208";a="47294536" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 25 Aug 2013 08:36:53 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 29610B4063; Sun, 25 Aug 2013 08:36:53 -0400 (EDT) Date: Sun, 25 Aug 2013 08:36:53 -0400 (EDT) From: Rick Macklem To: Michael Tratz Message-ID: <1329714843.13356290.1377434213149.JavaMail.root@uoguelph.ca> In-Reply-To: <40674FAC-33E6-4994-819E-6B8318B9DDB3@esosoft.com> Subject: Re: NFS deadlock on 9.2-Beta1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) 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, 25 Aug 2013 12:36:55 -0000 Michael Tratz wrote: > > On Aug 15, 2013, at 2:39 PM, Rick Macklem > wrote: > > > Michael Tratz wrote: > >> > >> On Jul 27, 2013, at 11:25 PM, Konstantin Belousov > >> wrote: > >> > >>> On Sat, Jul 27, 2013 at 03:13:05PM -0700, Michael Tratz wrote: > >>>> Let's assume the pid which started the deadlock is 14001 (it > >>>> will > >>>> be a different pid when we get the results, because the machine > >>>> has been restarted) > >>>> > >>>> I type: > >>>> > >>>> show proc 14001 > >>>> > >>>> I get the thread numbers from that output and type: > >>>> > >>>> show thread xxxxx > >>>> > >>>> for each one. > >>>> > >>>> And a trace for each thread with the command? > >>>> > >>>> tr xxxx > >>>> > >>>> Anything else I should try to get or do? Or is that not the data > >>>> at all you are looking for? > >>>> > >>> Yes, everything else which is listed in the 'debugging deadlocks' > >>> page > >>> must be provided, otherwise the deadlock cannot be tracked. > >>> > >>> The investigator should be able to see the whole deadlock chain > >>> (loop) > >>> to make any useful advance. > >> > >> Ok, I have made some excellent progress in debugging the NFS > >> deadlock. > >> > >> Rick! You are genius. :-) You found the right commit r250907 > >> (dated > >> May 22) is the definitely the problem. > >> > >> Here is how I did the testing: One machine received a kernel > >> before > >> r250907, the second machine received a kernel after r250907. Sure > >> enough within a few hours the machine with r250907 went into the > >> usual deadlock state. The machine without that commit kept on > >> working fine. Then I went back to the latest revision (r253726), > >> but > >> leaving r250907 out. The machines have been running happy and rock > >> solid without any deadlocks. I have expanded the testing to 3 > >> machines now and no reports of any issues. > >> > >> I guess now Konstantin has to figure out why that commit is > >> causing > >> the deadlock. Lovely! :-) I will get that information as soon as > >> possible. I'm a little behind with normal work load, but I expect > >> to > >> have the data by Tuesday evening or Wednesday. > >> > > Have you been able to pass the debugging info on to Kostik? > > > > It would be really nice to get this fixed for FreeBSD9.2. > > > > Thanks for your help with this, rick > > Sorry Rick, I wasn't able to get you guys that info quickly enough. I > thought I would have enough time, before my own wedding and > honeymoon came along, but everything went a little crazy and > stressful. I didn't think it would be this nuts. :-) > > I'm caught up with everything and from what I can see from the > discussions is that we know now what the problem is. > > I can report that the machines which I have had without r250907 have > been running without any problems for 27+ days. > > If you need me to test any new patches, please let me know. If I > should test with the partial merge of r253927 I'll be happy to do > so. > It's up to you, but you might want to wait until the other tester (J. David?) reports back on success/failure. Thanks for your help with this, rick > Thanks, > > Michael > > > > > From owner-freebsd-stable@FreeBSD.ORG Sun Aug 25 14:13: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 74C75646; Sun, 25 Aug 2013 14:13:18 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3B82A2F6D; Sun, 25 Aug 2013 14:13:18 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id m16so1139040ieq.24 for ; Sun, 25 Aug 2013 07:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZrN1ds4zQD2rZY10E4cGEyDM4Q+R/gRVZs+ObkAYnEU=; b=U+mA4Js4frHw+M/4dlZqc/dkjMwXMRRpDqD36RWzdHMJ/OQT527NeSDGRUJNGT/R9L /TRuklOgKe3q+GJm+fms1/eoFai5fBQkHgzbz8p7oGCtedXgJPAiHqJUJSctSFl3dhq8 T25HxRuyJJvpzEYf5UVW9AFpeKJSBw22ZazRU9gTA/OV5LzrljYqj8cvq3vjOYR87cAr caftl0gxVz+ZoinRH4rFyKF2ZrARgrJJYcK1j17zqxpcZqquMRf3Q+QV1/1+wFDTrNjA d9ThWyz892714MtoL6yDD94dRcX6MSqcnvLnTUnhNhcebTKmRvW5HwQAUmM+FI2swthl RGzQ== MIME-Version: 1.0 X-Received: by 10.50.20.195 with SMTP id p3mr3897215ige.26.1377439997667; Sun, 25 Aug 2013 07:13:17 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.42.150.196 with HTTP; Sun, 25 Aug 2013 07:13:17 -0700 (PDT) In-Reply-To: References: <461392652.9990692.1376602743970.JavaMail.root@uoguelph.ca> <40674FAC-33E6-4994-819E-6B8318B9DDB3@esosoft.com> Date: Sun, 25 Aug 2013 10:13:17 -0400 X-Google-Sender-Auth: F7lVrIhtxY5SxdDK2x_H7bB4vSY Message-ID: Subject: Re: NFS deadlock on 9.2-Beta1 From: J David To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Rick Macklem , FreeBSD Stable Mailing List , Michael Tratz 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, 25 Aug 2013 14:13:18 -0000 On Sun, Aug 25, 2013 at 7:42 AM, Adrian Chadd wrote: > Does -HEAD have this same problem? If I understood kib@ correctly, this is fixed in -HEAD by r253927. > If so, we should likely just revert the patch entirely from -HEAD and -9 > until it's resolved. It was not too difficult to prepare a releng/9.2 build with r254754 reverted (reverting the revert) and then applying kib@'s suggested backport fix. So far that is running on 9 nodes with no reported problems, but only since last night. We were hesitant to do the significant work involved to push it out to dozens of nodes if nobody was going to consider it for 9.2 anyway. Thanks! From owner-freebsd-stable@FreeBSD.ORG Sun Aug 25 14:19:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 870CD7FD; Sun, 25 Aug 2013 14:19:46 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (aran.keltia.net [88.191.250.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4BCA32FAC; Sun, 25 Aug 2013 14:19:45 +0000 (UTC) Received: from lonrach.local (unknown [IPv6:2a01:e34:ee87:4a00:fc3e:26b0:e8f8:2c6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix) with ESMTPSA id 28B7E52AE; Sun, 25 Aug 2013 16:19:47 +0200 (CEST) Date: Sun, 25 Aug 2013 16:19:42 +0200 From: Ollivier Robert To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: patch to improve AES-NI performance Message-ID: <20130825141942.GB19969@lonrach.local> References: <20130822202027.GH94127@funkthat.com> <20130823151615.GD41379@roberto02-aw.erc.corp.eurocontrol.int> <20130823180413.GL94127@funkthat.com> <20130823182752.GA15392@lonrach.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130823182752.GA15392@lonrach.local> X-Operating-System: MacOS X / MBP 4,1 - FreeBSD 8.0 / T3500-E5520 Nehalem User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 14:19:46 -0000 According to Ollivier Robert: > You are right, I wanted to say r226837 which is the "code" one. FYI I've finally merged r226837,r226839 as r254856 in stable/9 as it is a prerequesite to apply jmg's patch. I've asked re@ whether they would consider this for 9.2. It is very late in the 9.2 release circle but that patch has been in 10 for more than a year now... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-stable@FreeBSD.ORG Sun Aug 25 19:41: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C33168E7 for ; Sun, 25 Aug 2013 19:41:45 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 85D332EA3 for ; Sun, 25 Aug 2013 19:41:44 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-134-3-231-194.hsi14.kabel-badenwuerttemberg.de [134.3.231.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id A1DC486251 for ; Sun, 25 Aug 2013 21:41:36 +0200 (CEST) Message-ID: <521A5DEF.2010708@bsdforen.de> Date: Sun, 25 Aug 2013 21:41:35 +0200 From: Dominic Fandrey MIME-Version: 1.0 To: FreeBSD Stable Mailing List Subject: [panic] vm_page_unwire: page 0xfffffe02377e42a0's wire count is zero Content-Type: text/plain; charset=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: Sun, 25 Aug 2013 19:41:45 -0000 Finally I got some hard data in the "stopping amd causes a freeze" case. I turned off xdm and reproduced the panic a couple of times by creating high tmpfs load (building chromium on tmpfs) and sending SIGTERM to amd. I got a couple of panics that produced many screens of output but instantly rebooted. Note that nothing was actually mounted by amd, when SIGTERM was sent. But once the system froze instead. I took a picture, but it turned out I was actually rewarded with a textdump, which I am willing to mail to all interested parties. I still don't get cores (the system is set up for minidumps), but that's much better than just saying that the system freezes/reboots when I do a, b and c. Any way, here is the juice: FreeBSD 9.2-PRERELEASE #0 r254857: Sun Aug 25 16:28:26 CEST 2013 root@mobileKamikaze.norad:/usr/obj/HP6510b-9/amd64/usr/src/sys/HP6510b-9 db:0:kdb.enter.panic> run lockinfo db:1:lockinfo> show locks No such command db:1:locks> show alllocks No such command db:1:alllocks> show lockedvnods Locked vnodes db:0:kdb.enter.panic> show pcpu cpuid = 1 dynamic pcpu = 0xffffff807ee89280 curthread = 0xfffffe01c80fd490: pid 3070 "amd" curpcb = 0xffffff824f85ad00 fpcurthread = 0xfffffe01c80fd490: pid 3070 "amd" idlethread = 0xfffffe000521b000: tid 100004 "idle: cpu1" curpmap = 0xffffffff813f1e18 tssp = 0xffffffff8145fb68 commontssp = 0xffffffff8145fb68 rsp0 = 0xffffff824f85ad00 gs32p = 0xffffffff8145dca0 ldt = 0xffffffff8145dce0 tss = 0xffffffff8145dcd0 db:0:kdb.enter.panic> bt Tracing pid 3070 tid 100138 td 0xfffffe01c80fd490 kdb_enter() at kdb_enter+0x3b/frame 0xffffff824f85a850 panic() at panic+0x1c6/frame 0xffffff824f85a950 vm_page_unwire() at vm_page_unwire+0xf5/frame 0xffffff824f85a980 vm_fault_unwire() at vm_fault_unwire+0xb2/frame 0xffffff824f85a9c0 vm_map_delete() at vm_map_delete+0xcf/frame 0xffffff824f85aa30 vm_map_remove() at vm_map_remove+0x59/frame 0xffffff824f85aa60 vmspace_exit() at vmspace_exit+0xc7/frame 0xffffff824f85aa90 exit1() at exit1+0x3e0/frame 0xffffff824f85ab00 sys_sys_exit() at sys_sys_exit+0xe/frame 0xffffff824f85ab10 amd64_syscall() at amd64_syscall+0x5ea/frame 0xffffff824f85ac30 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xffffff824f85ac30 --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x800af5b3c, rsp = 0x7fffffffd8c8, rbp = 0x7fffffffdaa8 --- -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Sun Aug 25 20:43:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1121) id E99201C9; Sun, 25 Aug 2013 20:43:11 +0000 (UTC) Date: Sun, 25 Aug 2013 20:43:11 +0000 To: Thomas Mueller Subject: Re: Change in loader or kernel: won't boot with kfreebsd in grub2 Message-ID: <20130825204311.GA61785@hub.freebsd.org> References: <339077.27046.bm@smtp105.sbc.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <339077.27046.bm@smtp105.sbc.mail.bf1.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) From: nox@FreeBSD.ORG (Juergen Lock) Cc: "Andrey V. Elsukov" , freebsd-stable@freebsd.org, Juergen Lock 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, 25 Aug 2013 20:43:12 -0000 On Sat, Aug 24, 2013 at 08:53:31PM -0700, Thomas Mueller wrote: > Some updates: > > I could see what happens if I try to boot the FreeBSD boot partition on the hard drive using the Super Grub Disk with chainloader. > > If that works, it would boot FreeBSD 9.0-BETA1, but I would see if it works. > > That failed (invalid signature). > You probably need to chainload a freebsd-boot partition, _if_ you want to chainload at all. > I could also try > kfreebsd /boot/kernel/kernel > > That failed to boot the proper partition, went to the debugger (db>), whereupon all I could type was "reboot". > You didn't get a mountroot prompt? If you did you can try typing a question mark and return, that should list possible partitions to mount root from. If you didn't, or you don't want to do this manually you need to set kFreeBSD.vfs.root.mountfrom=ufs:/dev/ada0p1 from grub2, or wherever your root partition is. > Now can I safely install boot into the partition to be booted, as I did with NetBSD on USB stick? > > gpart -p /boot/boot -i 3 > > That would be for /dev/ada0p3, but I am afraid of damaging something. > That would need to be on a freebsd-boot partition, and you want /boot/gptboot not /boot/boot. > Tom > HTH, Juergen From owner-freebsd-stable@FreeBSD.ORG Sun Aug 25 22:41:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A315E297 for ; Sun, 25 Aug 2013 22:41:54 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) Received: from nm8.access.bullet.mail.bf1.yahoo.com (nm8.access.bullet.mail.bf1.yahoo.com [216.109.114.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 42B3926B8 for ; Sun, 25 Aug 2013 22:41:54 +0000 (UTC) Received: from [66.196.81.162] by nm8.access.bullet.mail.bf1.yahoo.com with NNFMP; 25 Aug 2013 22:35:06 -0000 Received: from [98.139.221.50] by tm8.access.bullet.mail.bf1.yahoo.com with NNFMP; 25 Aug 2013 22:35:06 -0000 Received: from [127.0.0.1] by smtp103.sbc.mail.bf1.yahoo.com with NNFMP; 25 Aug 2013 22:35:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1377470106; bh=h575k7tdI2DSe/vD4eLbeo1a8pjSZbaqHSOW9MenFgw=; h=X-Yahoo-Newman-Id:Message-ID:Date:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:To:CC:Subject; b=E+f9SrhkWfOwL8WHHdri6FjET3GNmbDDhhQx9UylqMbKcCWBaxIj5cEijoXrTDDcGX+geET/ZROiEhfYaxjavi2i5nm3PeklLP5UbI02PzDr/WuU0VzNvHRshjCTkhL5+SpS8nbhKZ7a17zZXQm+c8DY1F9cXKG+AyZc/Vm5ICc= X-Yahoo-Newman-Id: 429990.38961.bm@smtp103.sbc.mail.bf1.yahoo.com Message-ID: <429990.38961.bm@smtp103.sbc.mail.bf1.yahoo.com> Date: Sun, 25 Aug 2013 15:35:06 -0700 (PDT) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Ne8MyWYVM1kGusRgtZo7e4GlTnYb86OHopQDdhgeg33bev5 NF90bKUsOkwGBx_tfMQvq9xaKSMJSdRR7ae3ZM5Lx.AD36fqMFRM55euBs9h ILiTDYjcBO37YcIIdaBPXTE9gFWz575fpjTIJWtnrjb2fp6kV_DMGmbbLld7 eWxHjtONABuBxqojjdesTmVIFADzcM88.84xfnTVFjHH2lkYEnp2FKmTbwUX TPzii8.ddMCs2xn4G6HI9Azd6e0pvXZ0EN1.cwg.Z08NCpGEs3b9iovf6g1. HjfrrOnCf_6__TmZmYI8YUESE4pXUY4ER53scvC6_If6Gvt2Xhktm9vCLRZm dl1a6cnErTtXL1InkmByEKSsaOlrO9ni3pYI5S8keNIew7W6EObFjud_ZNR7 GMcWE8pHaKvmBs5UZ.vR59HLO7DimY3x6joFeESqVDsUJQFJVyfEsvS9acqh R516m9Wx27BTU04G9.ySHgbWBCRgB5RpduPlMc5uleZ8IU6eC.FRriS4X1Zx s8rE2W2FHfuAnX68ocTmVc3RwQCVO7Kf3rvQ6iReScQ6UsRnPfgoCzqxCsdO ObUNZcfL8 X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- X-Rocket-Received: from localhost (mueller6724@74.130.200.176 with plain) by smtp103.sbc.mail.bf1.yahoo.com with SMTP; 25 Aug 2013 15:35:06 -0700 PDT From: "Thomas Mueller" To: freebsd-stable@freebsd.org Subject: Re: Change in loader or kernel: won't boot with kfreebsd in grub2 Cc: "Andrey V. Elsukov" , Juergen Lock 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, 25 Aug 2013 22:41:54 -0000 > On Sat, Aug 24, 2013 at 08:53:31PM -0700, Thomas Mueller wrote: > > Some updates: > > I could see what happens if I try to boot the FreeBSD boot partition on the hard drive using the Super Grub Disk with chainloader. > > If that works, it would boot FreeBSD 9.0-BETA1, but I would see if it works. > > That failed (invalid signature). > You probably need to chainload a freebsd-boot partition, _if_ you > want to chainload at all. I was trying to chainload the freebsd-boot partition! But grub2 didn't like it. > > I could also try > > kfreebsd /boot/kernel/kernel > > That failed to boot the proper partition, went to the debugger (db>), whereupon all I could type was "reboot". > You didn't get a mountroot prompt? If you did you can try typing a > question mark and return, that should list possible partitions to mount > root from. If you didn't, or you don't want to do this manually you > need to set kFreeBSD.vfs.root.mountfrom=ufs:/dev/ada0p1 from grub2, > or wherever your root partition is. I remember pressing a key, but then the system rushed past the mountroot prompt into the debugger prompt. > > Now can I safely install boot into the partition to be booted, as I did with NetBSD on USB stick? > > gpart -p /boot/boot -i 3 > > That would be for /dev/ada0p3, but I am afraid of damaging something. > That would need to be on a freebsd-boot partition, and you want > /boot/gptboot not /boot/boot. I believe bsdlabel can be used to install boot code to a partition, but believe that is not for GPT. I could try bsdlabel on a giant floppy image as I used installboot on a giant floppy image for NetBSD. > Tom > HTH, > Juergen Tom From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 07:06:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F2921970 for ; Mon, 26 Aug 2013 07:06:54 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from s1.omnilan.de (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6669B2D21 for ; Mon, 26 Aug 2013 07:06:54 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by s1.omnilan.de (8.13.8/8.13.8) with ESMTP id r7Q76huN023138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Aug 2013 09:06:44 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <521AFE7E.2040705@omnilan.de> Date: Mon, 26 Aug 2013 09:06:38 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: if_em, legacy nic and GbE saturation X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD5E68D27A12A0C935A3A0037" 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, 26 Aug 2013 07:06:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD5E68D27A12A0C935A3A0037 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, I recycled an older box and put an i350-2 together with a second 82541GI (PCI-slot, one already on-board) into it. The two i350-ports are used with VMDq for ESXi5.1. The two 82541GI are used as lagg-nics by a 9.2-RC (amd64) guest as passthrou PCI device. Always had good results with such setups, but found out, that nics which use the legacy driver part of if_em max out at ~0.6Gbits/s (1500 MTU). There's another NIC on board of this recycle-box, a 82566-PHY (ICH9 integrated MAC). This one uses also if_em, but not legacy code, it reports version 7.3.8 (compared to 1.0.6). And it has no problem fully saturating GbE (~925Mbits/s, no jumbo Frames support anyways). I'm using iperf, with and without lagg (doesn't change anyhing, like it doesn't influence tests on some other boxes with 82576 and i350 (igb)) I see enough idle cycles so CPU shouldn't limit the legacy if_em nics. Also, I see the 82541 consuming arround 8k irqs. Same does the 82566-PHY, but with much higher throughput... I'd like to know if I can't generally expect to saturate older (PCI) GbE nics the line for any reason... I can remember tigeon cards from more than a decade ago, which indeed seemd to lack the performance to gain GbE, but I thought that was no issue shortly later and no "modern" Intel-GbE card had such constraints!? Is there any special tuning for legacy if_em (no need for any TCP tuning, 82566 doesn't have any issue)? Thanks, -Harry --------------enigD5E68D27A12A0C935A3A0037 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlIa/oMACgkQLDqVQ9VXb8hOGgCgpr/IGqH1zfmwOUuAMMA3bJXT 1J8AnRzwq89uWdIEUC5krugJEU8V645k =sDBx -----END PGP SIGNATURE----- --------------enigD5E68D27A12A0C935A3A0037-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 08:09:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 45F8C591; Mon, 26 Aug 2013 08:09:00 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 0587F2101; Mon, 26 Aug 2013 08:08:59 +0000 (UTC) Received: from mobileKamikaze.norad (MN-VPN2.HS-Karlsruhe.DE [193.196.117.63]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id E1F6B86232; Mon, 26 Aug 2013 10:08:56 +0200 (CEST) Message-ID: <521B0D18.2030100@bsdforen.de> Date: Mon, 26 Aug 2013 10:08:56 +0200 From: Dominic Fandrey MIME-Version: 1.0 To: Victor Balada Diaz Subject: Re: wpi fatal firmware error with country de References: <521100E2.2090405@bsdforen.de> <5211358F.9000005@bsdforen.de> <52114A38.4080309@bsdforen.de> <20130824155759.GH14858@equilibrium.bsdes.net> In-Reply-To: <20130824155759.GH14858@equilibrium.bsdes.net> Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , FreeBSD Stable Mailing List 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, 26 Aug 2013 08:09:00 -0000 On 24/08/2013 17:57, Victor Balada Diaz wrote: > On Mon, Aug 19, 2013 at 12:27:04AM +0200, Dominic Fandrey wrote: >> On 19/08/2013 00:13, Adrian Chadd wrote: >>> That's really odd. But then, it's a firmware driven NIC, who knows what >>> kind of weird crap is going on under the hood. >> >> Yes, it's a black box. So how do I get in contact with intel support and >> dump that in their laps? >> >>> Maybe you could experiment by looking at what changing the regulatory >>> domain does when programming the firmware and see if it's a channel thing, >>> a regulatory domain thing or something else. >> >> It looks like anything that results in regdomain FCC is all right. >> Everything else blows up. > > I've reported the same issue nearly a year ago: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172706 > > If you get to find additional information, please add it to > the PR so it doesn't get lost. > > I didn't actually find any way to fix it. Sorry, I've got nothing. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 08:34:47 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9EB04F6E for ; Mon, 26 Aug 2013 08:34:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6145C23AC for ; Mon, 26 Aug 2013 08:34:47 +0000 (UTC) Received: by mail-qe0-f44.google.com with SMTP id 5so1604813qeb.3 for ; Mon, 26 Aug 2013 01:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6Ds1RzTHymgkOajSmkrn+Ecsq5Fc2WCaGlKk76p/oBw=; b=mwgy2cJjhjzGB/7GzM4deI1+3jwpeT/XpWERBRigf+AgPPAdsndMvI0Y9jDrU3K02d CaKIDv1OZeyf+wmeVk3tMLRO1WBG7Q6A1mCiKLDtCyLFaoc8ayhZVsCSTItGfaDvHT8V 8+4WuJv/wRGXgU2+e/1zEgVNmClpbTN3PrCzaGx0Fqp4VsnlbIX44eahhv2DGY1GHPqg Dpo4MHk/KEup7FblaQ9FZOhfmBSF53SdKraCWtr98a6hdp9Ywv7A7uYnH17iQ1lsK14G 4+185PbtF0W/9SBBE8dm0mFgQ3RaxfjxZ8epCRVhvSc6LczUpTVy7ApeG1AYRwD1+vOe BNEg== MIME-Version: 1.0 X-Received: by 10.224.66.74 with SMTP id m10mr14880760qai.12.1377506086401; Mon, 26 Aug 2013 01:34:46 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Mon, 26 Aug 2013 01:34:46 -0700 (PDT) In-Reply-To: <521AFE7E.2040705@omnilan.de> References: <521AFE7E.2040705@omnilan.de> Date: Mon, 26 Aug 2013 01:34:46 -0700 X-Google-Sender-Auth: oGPvsLfQzfY-4Llk5D5_Wu7Ts_0 Message-ID: Subject: Re: if_em, legacy nic and GbE saturation From: Adrian Chadd To: Harald Schmalzbauer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List 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, 26 Aug 2013 08:34:47 -0000 Hi, There's bus limits on how much data you can push over a PCI bus. You can look around online to see what 32/64 bit, 33/66MHz PCI throughput estimates are. It changes massively if you use small versus large frames as well. The last time I tried it i couldn't hit gige on PCI; I only managed to get to around 350mbit doing TCP tests. -adrian On 26 August 2013 00:06, Harald Schmalzbauer wrote: > Hello, > > I recycled an older box and put an i350-2 together with a second 82541GI > (PCI-slot, one already on-board) into it. > The two i350-ports are used with VMDq for ESXi5.1. > The two 82541GI are used as lagg-nics by a 9.2-RC (amd64) guest as > passthrou PCI device. > Always had good results with such setups, but found out, that nics which > use the legacy driver part of if_em max out at ~0.6Gbits/s (1500 MTU). > > There's another NIC on board of this recycle-box, a 82566-PHY (ICH9 > integrated MAC). > This one uses also if_em, but not legacy code, it reports version 7.3.8 > (compared to 1.0.6). > And it has no problem fully saturating GbE (~925Mbits/s, no jumbo Frames > support anyways). > > I'm using iperf, with and without lagg (doesn't change anyhing, like it > doesn't influence tests on some other boxes with 82576 and i350 (igb)) > I see enough idle cycles so CPU shouldn't limit the legacy if_em nics. > Also, I see the 82541 consuming arround 8k irqs. Same does the > 82566-PHY, but with much higher throughput... > > I'd like to know if I can't generally expect to saturate older (PCI) GbE > nics the line for any reason... I can remember tigeon cards from more > than a decade ago, which indeed seemd to lack the performance to gain > GbE, but I thought that was no issue shortly later and no "modern" > Intel-GbE card had such constraints!? > Is there any special tuning for legacy if_em (no need for any TCP > tuning, 82566 doesn't have any issue)? > > Thanks, > > -Harry > > From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 09:28:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 856DB320; Mon, 26 Aug 2013 09:28:58 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from s1.omnilan.de (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EB5AE2BC0; Mon, 26 Aug 2013 09:28:56 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by s1.omnilan.de (8.13.8/8.13.8) with ESMTP id r7Q9Sqtm024928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Aug 2013 11:28:53 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <521B1FD4.4050702@omnilan.de> Date: Mon, 26 Aug 2013 11:28:52 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: if_em, legacy nic and GbE saturation References: <521AFE7E.2040705@omnilan.de> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0C892B502D9084CC08DA245B" Cc: FreeBSD Stable Mailing List 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, 26 Aug 2013 09:28:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0C892B502D9084CC08DA245B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bez=FCglich Adrian Chadd's Nachricht vom 26.08.2013 10:34 (localtime): > Hi, > > There's bus limits on how much data you can push over a PCI bus. You > can look around online to see what 32/64 bit, 33/66MHz PCI throughput > estimates are. > > It changes massively if you use small versus large frames as well. > > The last time I tried it i couldn't hit gige on PCI; I only managed to > get to around 350mbit doing TCP tests. Thanks, I'm roughly aware about the PCI bus limit, but I guess it should be good for almost GbE: 33*10^6*32=3D1056, so if one considers overhead and other bus-blocking things (nothing of significance is active on the PCI bus in this case), I'd expect at least 800Mbis/s, which is what I get with jumbo frames. I also know that lagg won't help in regard of concurrent throughput because of the PCI limit. But it's the redundancy why I also use 2 nics in that parking-maschine. I just have no explanation why I see that noticable difference between mtu 1500 and 9000 on legacy if_em nic, which doesn't show up with the second on-board nic (82566), which uses different if_em code. I can imagine that it's related to PCI transfer limits (the 82566 is ICH9 integrated which connects via DMI to the CPU, so no PCI constraint), but if someone has more than an imagination, an explanation was highly appreciated :-) But if you saw similar constraints on other (non-if_em?) PCI-connected nics, I'll leave it as it is. Just wanted some kind of confirmation that it's normal that single-GbE doesn't play well with PCI. Thank you, -Harry --------------enig0C892B502D9084CC08DA245B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlIbH9QACgkQLDqVQ9VXb8iWmgCfenebOJrkeWbv5ux+hlg3Cwt5 400AnRfeET7T6kwHzFoH8HwmCLTOXyUF =Vf8y -----END PGP SIGNATURE----- --------------enig0C892B502D9084CC08DA245B-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 09:50:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 708CCB98 for ; Mon, 26 Aug 2013 09:50:44 +0000 (UTC) (envelope-from maurizio.vairani@cloverinformatica.it) Received: from smtpdg9.aruba.it (smtpdg8.aruba.it [62.149.158.238]) by mx1.freebsd.org (Postfix) with ESMTP id C82112E52 for ; Mon, 26 Aug 2013 09:50:43 +0000 (UTC) Received: from cloverinformatica.it ([188.10.129.202]) by smtpcmd03.ad.aruba.it with bizsmtp id HMpV1m01b4N8xN401MpW1Y; Mon, 26 Aug 2013 11:49:31 +0200 Received: from [192.168.0.81] (ASUS-TERMINATOR [192.168.0.81]) by cloverinformatica.it (Postfix) with ESMTP id 88DB913E88; Mon, 26 Aug 2013 11:49:30 +0200 (CEST) Message-ID: <521B24AA.50200@cloverinformatica.it> Date: Mon, 26 Aug 2013 11:49:30 +0200 From: Maurizio Vairani User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ronald Klop Subject: Re: [SOLVED] Re: Shutdown problem with an USB memory stick as ZFS cache device References: <201307171529.r6HFT4EK063849@fire.js.berklix.net> <51E79EAD.5040602@cloverinformatica.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 09:50:44 -0000 On 24/07/2013 13.19, Ronald Klop wrote: > On Thu, 18 Jul 2013 09:52:13 +0200, Maurizio Vairani > wrote: > >> On 17/07/2013 17:29, Julian H. Stacey wrote: >>> Maurizio Vairani wrote: >>>> On 17/07/2013 11:50, Ronald Klop wrote: >>>>> On Wed, 17 Jul 2013 10:27:09 +0200, Maurizio Vairani >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> >>>>>> on a Compaq Presario laptop I have just installed the latest stable >>>>>> >>>>>> >>>>>> #uname -a >>>>>> >>>>>> FreeBSD presario 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0: Tue >>>>>> Jul 16 >>>>>> 16:32:39 CEST 2013 >>>>>> root@presario:/usr/obj/usr/src/sys/GENERIC amd64 >>>>>> >>>>>> >>>>>> For speed up the compilation I have added to the pool, tank0, a >>>>>> SanDisk memory stick as cache device with the command: >>>>>> >>>>>> >>>>>> # zpool add tank0 cache /dev/da0 >>>>>> >>>>>> >>>>>> But when I shutdown the laptop the process will halt with this >>>>>> screen >>>>>> shot: >>>>>> >>>>>> >>>>>> http://www.dump-it.fr/freebsd-screen-shot/2f9169f18c7c77e52e873580f9c2d4bf.jpg.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> and I need to press the power button for more than 4 seconds to >>>>>> switch off the laptop. >>>>>> >>>>>> The problem is always reproducible. >>>>> Does sysctl hw.usb.no_shutdown_wait=1 help? >>>>> >>>>> Ronald. >>>> Thank you Ronald it works ! >>>> >>>> In /boot/loader.conf added the line >>>> hw.usb.no_shutdown_wait=1 >>>> >>>> Maurizio >>> I wonder (from ignorance as I dont use ZFS yet), >>> if that merely masks the symptom or cures the fault ? >>> >>> Presumably one should use a ZFS command to disassociate whatever >>> might have the cache open ? (in case something might need to be >>> written out from cache, if it was a writeable cache ?) >>> >>> I too had a USB shutdown problem (non ZFS, now solved)& several people >>> made useful comments on shutdown scripts etc, so I'm cross referencing: >>> >>> http://lists.freebsd.org/pipermail/freebsd-mobile/2013-July/012803.html >>> >>> Cheers, >>> Julian >> Probably it masks the symptom. Andriy Gapon hypothesizes a bug in the >> ZFS clean up code: >> http://lists.freebsd.org/pipermail/freebsd-fs/2013-July/017857.html >> >> Surely one can use a startup script with the command: >> zpool add tank0 cache /dev/da0 >> and a shutdown script with: >> zpool remove tank0 /dev/da0 >> but this mask the symptom too. >> >> I prefer the Ronald solution because: >> - is simpler: it adds only one line (hw.usb.no_shutdown_wait=1) to >> one file (/boot/loader.conf). >> - is fastest: the zpool add/remove commands take time and >> “hw.usb.no_shutdown_wait=1” in /boot/loader.conf speeds up the >> shutdown process. >> - is cleaner: the zpool add/remove commands pair will fill up the >> tank0 pool history. >> >> Regards >> Maurizio > > Keep an eye on this commit when it is merged to 9-stable. > http://svnweb.freebsd.org/changeset/base/253606 > It might be the fix of the problem. > > Ronald. It works ! Just upgraded the laptop to r254783. Shutdown and reboot works fine, regardless of the hw.usb.no_shutdown_wait value. Thanks Maurizio From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 13:13:08 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E94E3AB8; Mon, 26 Aug 2013 13:13:07 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF7C12338; Mon, 26 Aug 2013 13:13:07 +0000 (UTC) Received: from glenbarber.us (unknown [IPv6:2001:470:8:1205:701e:d184:9d94:ba66]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 4137C24B9; Mon, 26 Aug 2013 13:13:06 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 4137C24B9 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Mon, 26 Aug 2013 09:13:03 -0400 From: Glen Barber To: freebsd-stable@FreeBSD.org Subject: 9.2-RC3 Now Available Message-ID: <20130826131303.GA49310@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" 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: Mon, 26 Aug 2013 13:13:08 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The third release candidate builds of the 9.2-RELEASE release cycle are now available on the FTP servers for the amd64, i386, ia64, powerpc, powerpc64, and sparc64 architectures. This is expected to be the final release candidate for the 9.2-RELEASE cycle. The image checksums follow at the end of this email. ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.2/ (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/9.2". Please be aware that cvsup and CVS are both deprecated, and are not supported methods of updating the src/ tree. Changes between -RC2 and -RC3 include: o Fix an integer overflow in computing the size of a temporary buffer, which can result in a buffer which is too small for the requested operation. (FreeBSD-SA-13:09.ip_multicast) o Revert fixes and improvements to sendfile(2), which uncovered a bug in the NFS implementation that in turn can cause deadlocks. o Default net.inet.tcp.experimental.initcwnd10 to off. The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 9.2-RC3 During this process, freebsd-update(8) 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 8.x. Alternatively, the user can install misc/compat8x 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: amd64: SHA256 (FreeBSD-9.2-RC3-amd64-bootonly.iso) = f981e308b638b754418a359bf200bb8287733cfab7c0baa6440950104e406160 SHA256 (FreeBSD-9.2-RC3-amd64-disc1.iso) = aea3dbbc6fb11eea71ebbce71e8b0b0dcc3e6b66846040a420c6097acb3a93d4 SHA256 (FreeBSD-9.2-RC3-amd64-dvd1.iso) = a3ab1daea0af0dbc5a790a384390f6d1f91d2d385215d2d3de5ea7a332b01919 SHA256 (FreeBSD-9.2-RC3-amd64-memstick.img) = ba7b8d1ce52b8e00213eb7c3551eb2c4d4ed9b02150310cd4f598290e119b4bf MD5 (FreeBSD-9.2-RC3-amd64-bootonly.iso) = d247cc4ca217a964f479dbe8cfc22fc0 MD5 (FreeBSD-9.2-RC3-amd64-disc1.iso) = 4e430da45f95cf861747cdad71c0cbe8 MD5 (FreeBSD-9.2-RC3-amd64-dvd1.iso) = 4eef235c2be6653eaea922dbebf7a33e MD5 (FreeBSD-9.2-RC3-amd64-memstick.img) = 32a77a37bea65773794ff41745709988 i386: SHA256 (FreeBSD-9.2-RC3-i386-bootonly.iso) = 68d36132ce13b39079641adc688f6e6a51dfce1d0a3dde4452e756d16bb5ddca SHA256 (FreeBSD-9.2-RC3-i386-disc1.iso) = 9e0a42a0622449092804da9ddf68a9b3d424d7535d13386e617e08e5059ec821 SHA256 (FreeBSD-9.2-RC3-i386-dvd1.iso) = be8f284d3c2958f04bbc94b482bfd7945c2b7464776a6de7912634e2b8a7dad8 SHA256 (FreeBSD-9.2-RC3-i386-memstick.img) = 4555133510cda8d38367a10cfd37b90eca9e194c137cfdabe264d5fac0b56aae MD5 (FreeBSD-9.2-RC3-i386-bootonly.iso) = 9f2d8496d9192a4ca1204cbbd9536d1a MD5 (FreeBSD-9.2-RC3-i386-disc1.iso) = 96bcc893a021e0d5e3c2b689c767569f MD5 (FreeBSD-9.2-RC3-i386-dvd1.iso) = 4562e0f482991c92ac86eee536eefd34 MD5 (FreeBSD-9.2-RC3-i386-memstick.img) = 47d9ab6b2cecd6791b4578e460259a27 ia64: SHA256 (FreeBSD-9.2-RC3-ia64-bootonly.iso) = 91608258d93a70c5941d927c10c0822b4e6b8a75b7493629b11caa765c6b57ce SHA256 (FreeBSD-9.2-RC3-ia64-disc1.iso) = 441978cbaaaf8e559ab3b856bad1ccacdca09d9a81e7fc1f6a3f8984191cdab9 SHA256 (FreeBSD-9.2-RC3-ia64-memstick.img) = d8506b3168fd5873515f0392afbfb525869cbf2b388580b749f39c845229eb5e MD5 (FreeBSD-9.2-RC3-ia64-bootonly.iso) = 781e8ac16d266cc1deaf9e9cbf795ffe MD5 (FreeBSD-9.2-RC3-ia64-disc1.iso) = 147bd004a65dfd565fb26dcb8101906f MD5 (FreeBSD-9.2-RC3-ia64-memstick.img) = db68dd2d741b483a015d123965b6f517 powerpc: SHA256 (FreeBSD-9.2-RC3-powerpc-bootonly.iso) = 56e66ae55cb475a7d075548393b1a0e71956a95dab3728645da569e2e0c94bdc SHA256 (FreeBSD-9.2-RC3-powerpc-disc1.iso) = f9abf5ee0b1fb9404219fe9fff577405875963d43fc5347cfdc5426e2036bfb3 SHA256 (FreeBSD-9.2-RC3-powerpc-memstick.img) = 65d284cbdeae605107e2c2799bd18de99dabbb9eb7989d1055e43fe9e97eca3d MD5 (FreeBSD-9.2-RC3-powerpc-bootonly.iso) = ce2b32e584adbfc82089674e41a97700 MD5 (FreeBSD-9.2-RC3-powerpc-disc1.iso) = fbf571c9c0d9dc1c259042f1ee691af9 MD5 (FreeBSD-9.2-RC3-powerpc-memstick.img) = 837fda0251d287a0b3d73c1342f62bf5 powerpc64: SHA256 (FreeBSD-9.2-RC3-powerpc-powerpc64-bootonly.iso) = 0bc1ac8817e329d41fb4b1d21e784e2223249a2eb2bcaf5059ef4d9daa0d69a8 SHA256 (FreeBSD-9.2-RC3-powerpc-powerpc64-disc1.iso) = 5a612c7ad11d179ec5144d0158efd08ca3d3437d1aed6de7c4130845b592ac8d SHA256 (FreeBSD-9.2-RC3-powerpc-powerpc64-memstick.img) = 60b9ba8a0d269b1b3135a9fa3e92a704ac9512c55af3fe4fb34ea2e390e31b16 MD5 (FreeBSD-9.2-RC3-powerpc-powerpc64-bootonly.iso) = 201fca2a2e9e9ebbeb4b18376715ac8b MD5 (FreeBSD-9.2-RC3-powerpc-powerpc64-disc1.iso) = 82465b995dc9df2d59d795573ea0fd66 MD5 (FreeBSD-9.2-RC3-powerpc-powerpc64-memstick.img) = af6cd64be1e0270aca628a666a5eb400 sparc64: SHA256 (FreeBSD-9.2-RC3-sparc64-bootonly.iso) = 0a8611aaed1ebe46212b2458db9e76e2000d7c761d96e3b283d9f4eec23cd2b5 SHA256 (FreeBSD-9.2-RC3-sparc64-disc1.iso) = f4303b03fad64dcc9b1c07dd9a2ec3c7348a0969d1bc8257e45b4821d6bfa666 MD5 (FreeBSD-9.2-RC3-sparc64-bootonly.iso) = 183d65a0f375cda8a5c9a77e206821f1 MD5 (FreeBSD-9.2-RC3-sparc64-disc1.iso) = 11524053e714daa137d84df76d5c1e28 Glen --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBCAAGBQJSG1RfAAoJEFJPDDeguUaj4MQH/RXkxX5fxn4xsj/EYYLOpLKP Vi07W/O/sjwSrfgWM9YBBaqzRKARR7KSghcLvjzvZVUZvPXTwnFKe72Yv7bUKSt7 w5LidJ8LRYq/CLP10O/6bCCpji9sZkfXv2GvFYAyPK5BBHxnVHAi3NQZlFVnNojx 6ZAMJsUSI9KUQnEU+80TRc4sLWoPOk47YAWzUmupybu7DvmNiNjrah6QpPKkgkc7 TGxlob41VBSGbcoz3reJDR89kUrXI3QE9RVMyTVdZuwXmYQCxQCdc9V65oldE6GG /gya+2WtznVsND+Rx1bCf1MrQnrb0KApiX1X8qkGA9++rx6l9vsZf2LBuxjskf4= =hel6 -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 13:29:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D41C743D for ; Mon, 26 Aug 2013 13:29:58 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 909372455 for ; Mon, 26 Aug 2013 13:29:58 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VDwrj-0007ST-W6 for freebsd-stable@freebsd.org; Mon, 26 Aug 2013 15:29:55 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Aug 2013 15:29:55 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Aug 2013 15:29:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Subject: Re: 9.2-RC3 Now Available Date: Mon, 26 Aug 2013 15:29:44 +0200 Lines: 45 Message-ID: References: <20130826131303.GA49310@glenbarber.us> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2ATFFVSOUASRFTVPMMNJG" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130322 Thunderbird/17.0.4 In-Reply-To: <20130826131303.GA49310@glenbarber.us> X-Enigmail-Version: 1.5.1 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, 26 Aug 2013 13:29:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2ATFFVSOUASRFTVPMMNJG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Updated via svnup from releng/9.0 to releng/9.2 (r254910) and I got this in buildworld: cc1: warnings being treated as errors /usr/src/usr.bin/xinstall/xinstall.c: In function 'metadata_log': /usr/src/usr.bin/xinstall/xinstall.c:1331: warning: implicit declaration of function 'strsvis' /usr/src/usr.bin/xinstall/xinstall.c:1331: warning: nested extern declaration of 'strsvis' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 2 errors *** Error code 2 1 error *** Error code 2 1 error Shouldn't buildworld use includes from /usr/src and not from the installed system? ------enig2ATFFVSOUASRFTVPMMNJG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIbWEgACgkQ/QjVBj3/HSyoJgCfQlnRL8oLUH6ab8Xe2jy3L+Py WOcAn3LzKbt8H4CDgQal+kqqy1Hf0Id4 =Zrtp -----END PGP SIGNATURE----- ------enig2ATFFVSOUASRFTVPMMNJG-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 14:04: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A815710C for ; Mon, 26 Aug 2013 14:04:18 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5DD3B266B for ; Mon, 26 Aug 2013 14:04:18 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1VDxHA-0002XA-IZ; Mon, 26 Aug 2013 16:56:12 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-stable Subject: another? NFS deadlock on 9.2-PRERELEASE Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Aug 2013 16:56:12 +0300 From: Daniel Braniss Message-ID: Cc: Rick Macklem 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, 26 Aug 2013 14:04:18 -0000 I upgraded our web server, and only after 3 hours it hung :-( (as a side note, I have 2 other web servers, also running 9.2 doing great :-) go figure. anyways, in ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/0 is the info after a forced panic. my guts say its running out of resources - mainly network related, but can't pinpoint it. any help will be most welcomed cheers, danny From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 14:09:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BCDEE2D5 for ; Mon, 26 Aug 2013 14:09:04 +0000 (UTC) (envelope-from matthias.schuendehuette@siemens.com) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 510FE26AD for ; Mon, 26 Aug 2013 14:09:04 +0000 (UTC) Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.13.6/8.13.6) with ESMTP id r7QDuQDQ007276 for ; Mon, 26 Aug 2013 15:56:26 +0200 Received: from DEFTHW99ET7MSX.ww902.siemens.net ([157.163.145.4]) by mail1.sbs.de (8.13.6/8.13.6) with ESMTP id r7QDuQOr021396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 26 Aug 2013 15:56:26 +0200 Received: from DEFTHW99ERGMSX.ww902.siemens.net (139.22.70.132) by DEFTHW99ET7MSX.ww902.siemens.net (157.163.145.4) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 26 Aug 2013 15:56:26 +0200 Received: from DENBGAT9EI2MSX.ww902.siemens.net ([169.254.10.232]) by DEFTHW99ERGMSX.ww902.siemens.net ([139.22.70.132]) with mapi id 14.03.0146.000; Mon, 26 Aug 2013 15:56:26 +0200 From: "Schuendehuette, Matthias" To: "freebsd-stable@freebsd.org" Subject: Stack overflow with kernel r254683 Thread-Topic: Stack overflow with kernel r254683 Thread-Index: Ac6iZA2YH/5eY4y6Qu+VjO1qBsQVHg== Date: Mon, 26 Aug 2013 13:56:25 +0000 Message-ID: <1EFE239F82F279488E86A61C92D5E2DE03828F@DENBGAT9EI2MSX.ww902.siemens.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.43] Content-Type: text/plain; charset="iso-8859-1" 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: Mon, 26 Aug 2013 14:09:04 -0000 Hello, yesterday I got a kernel crash on my server (a ProLiant DL380 G5): "panic: stack overflow detected; backtrace may be corrupted" Kernel is "9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #7 r254683" The stack trace reads: #0 doadump (textdump=3D1) at pcpu.h:249 249 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=3D1) at pcpu.h:249 #1 0xc0668a4d in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0xc0668f07 in panic (fmt=3D0x104
) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0xc0691da2 in __stack_chk_fail () at /usr/src/sys/kern/stack_protector.c:17 #4 0xc7fdb175 in nfsrvd_setattr (nd=3D0xc73b4400, isdgram=3D-952596480, vp=3D0xc8001140, p=3D0xf405ecc8, exp=3D0xc07af7f0) at /usr/src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdserv.c:371 #5 0xc7fdb6e0 in nfsrvd_releaselckown (nd=3D0xc7442a00, isdgram=3D-9525964= 80, vp=3D0xc7388848, p=3D0xf405ecb8, exp=3D0x0) at /usr/src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdserv.c:3481 #6 0xc07af7f0 in svc_run_internal (pool=3D0xc7de8b80, ismaster=3D0) at /usr/src/sys/rpc/svc.c:1109 #7 0xc07b006d in svc_thread_start (arg=3D0xc7de8b80) at /usr/src/sys/rpc/svc.c:1200 #8 0xc06384f7 in fork_exit (callout=3D0xc07b0060 , arg=3D0xc7de8b80, frame=3D0xf405ed08) at /usr/src/sys/kern/kern_fork.c:= 992 #9 0xc08787c4 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:= 279 I have all the files in /var/crash, so if someone wants additional informat= ions I should be able to deliver them. The kernel config file is customized in the sense that I have removed kerne= l items, that aren't used on that machine. One major difference: I use < options NFSCLIENT # Network Filesystem Client < options NFSSERVER # Network Filesystem Server instead of > options NFSCL # New Network Filesystem Client > options NFSD # New Network Filesystem Server because a kernel a few weeks ago immediately crashed with the new NFS-code. But it seems now, that the old NFS-code is also somehow damaged. Ah, and I still have from older releases of FreeBSD the following loader options - do they still make sense? geom_vinum_load=3D"YES" kern.maxdsiz=3D"734003200" vm.pmap.shpgperproc=3D256 vm.pmap.pv_entry_max=3D3145728 'geom_vinum' is used as LVM only, no RAIDs are configured. This server is primarily a Samba server with the SMB-shares exported as NFS= -shares as well for the other *nix-servers around. Because this is the most loaded production server, testing is a bit difficu= lt, restricted to the evening and the weekends. On my two other FreeBSD machines I have no problems at all, one of them is = an identical ProLiant server with a nearly identical kernel config - runs l= ike a charm... Has someone a good advice or further questions? =20 with best regards Matthias Sch=FCndeh=FCtte From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 16:06:56 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3DD8D81D for ; Mon, 26 Aug 2013 16:06:56 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm10-vm1.bullet.mail.ird.yahoo.com (nm10-vm1.bullet.mail.ird.yahoo.com [77.238.189.93]) by mx1.freebsd.org (Postfix) with SMTP id 8BF792DC5 for ; Mon, 26 Aug 2013 16:06:55 +0000 (UTC) Received: from [77.238.189.48] by nm10.bullet.mail.ird.yahoo.com with NNFMP; 26 Aug 2013 16:06:48 -0000 Received: from [46.228.39.78] by tm1.bullet.mail.ird.yahoo.com with NNFMP; 26 Aug 2013 16:06:47 -0000 Received: from [127.0.0.1] by smtp115.mail.ir2.yahoo.com with NNFMP; 26 Aug 2013 16:06:47 -0000 X-Yahoo-Newman-Id: 798681.51677.bm@smtp115.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: NMnCut0VM1k7U6BqB7IVb04ASWIfYvPQNsON86VuEmh.mF2 DwZMvLF3jJ43JaWs2cTF9fed2.hpeQK.431qRqqm0Tc0hrmbQEw2EKt._LT3 dWkZSnwaSJdOlqyb_ZL5J71RQBtrxqQRD69q1kOVsdQcL.UYET0UH650xpGE 4Lc7zYIYXwj23qS9AwRBMp2.80.TKarEkoA8PdRzhDgrV9mUd0yIE25wXSWE OMhv3egvx0lcu_oZ3lB5GOQFqV7B6MD4lGqTRSQeFINOnJb6xSctJNqUI6Rt O1_Y3s81ZanUHnSTgfEqWr4Ng0bOhY5VECVk_S7QcP.xoeSAbdHOJ0wwgCtY KER.X.WXlml.27t_HYGCb88z1JG4y95k1BXKybwIHPrZKBfQ8JsdXH_GmM_c OrxXw9ZLRSIICUPDDmfpYAP.2d6uZP8_ubo2n4l4FVJKFjR9.kfryaWkIW1y mDt1UiBy_rn01x74EL9G2abvTha5HFbx_qHq6ZT1EcDNge_d.sWo0dNu_Qh6 LdBijOEGXUCakTuYYDVXKtz14U.pQLw-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-Rocket-Received: from [192.168.119.11] (se@84.154.99.225 with ) by smtp115.mail.ir2.yahoo.com with SMTP; 26 Aug 2013 16:06:47 +0000 UTC Message-ID: <521B7D0C.2010109@freebsd.org> Date: Mon, 26 Aug 2013 18:06:36 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Harald Schmalzbauer Subject: Re: if_em, legacy nic and GbE saturation References: <521AFE7E.2040705@omnilan.de> <521B1FD4.4050702@omnilan.de> In-Reply-To: <521B1FD4.4050702@omnilan.de> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: FreeBSD Stable Mailing List 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, 26 Aug 2013 16:06:56 -0000 Am 26.08.2013 11:28, schrieb Harald Schmalzbauer: > Bezglich Adrian Chadd's Nachricht vom 26.08.2013 10:34 > (localtime): >> Hi, >> >> There's bus limits on how much data you can push over a PCI bus. >> You can look around online to see what 32/64 bit, 33/66MHz PCI >> throughput estimates are. >> >> It changes massively if you use small versus large frames as >> well. >> >> The last time I tried it i couldn't hit gige on PCI; I only >> managed to get to around 350mbit doing TCP tests. > > Thanks, I'm roughly aware about the PCI bus limit, but I guess it > should be good for almost GbE: 33*10^6*32=1056, so if one considers > overhead and other bus-blocking things (nothing of significance is > active on the PCI bus in this case), I'd expect at least 800Mbis/s, > which is what I get with jumbo frames. But PCI bus throughput might be much lower than expected: - The arbitration overhead is quite high, in the order of 0.2 to 0.3us. - Depending on device capabilities and chip-set configuration and features there may be many more arbitration phases than one might expect. - A cache line flush is requested for data held in the CPU, unless the bus-master uses special transfer commands to indicate that the full cache line will be invalidated within the requested transfer. These overheads combined may reduce the effective PCI throughput to a fraction of the nominal performance (1/3 to 1/4 for bursts of 16 bytes). The "minimum grant" value is the minimum burst length the device wants (to avoid a buffer underrun/overrun due to too low effective bandwidth) the "maximum latency" corresponds to the number of PCI clocks the device is willing to wait for the bus to be granted (to avoid buffer underrun/overrun while waiting to get access to the bus granted). The maximum latency value is useful to calculate the maximum arbitration unit for which no device is stalled longer than allowed by MAXLAT. MINGNT and MAXLAT of a device can be displayed with pciconf: # pciconf -r -b pci0:1:0 0x3e:0x3f (e.g., for bus 0 device 1 function 0) The PCI bus will be "lost" whenever another device gets access to the bus, whether CPU or another PCI (or PCIe) device. Especially when simultanously sending and receiving packets with two Ethernet controllers, bus arbitration will occur for every 16 to 32 transfers (depending on bus arbiter settings and programmed MINGNT). Regards, STefan From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 19:07:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B4C7969C for ; Mon, 26 Aug 2013 19:07:44 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 690B028C5 for ; Mon, 26 Aug 2013 19:07:44 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.7/8.14.5) with ESMTP id r7QJ7iI2082411 for ; Mon, 26 Aug 2013 15:07:44 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <521BA77E.3000603@sentex.net> Date: Mon, 26 Aug 2013 15:07:42 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List Subject: RELENG_9 build error X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 on 64.7.153.18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 19:07:44 -0000 Does anyone have any idea how to correct this issue ? Already blew away /usr/src and /usr/obj in case something got corrupted. cc -O2 -pipe -DDES -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o ed buf.o cbc.o glbl.o io.o main.o re.o sub.o undo.o -lcrypto gzip -cn /usr/src/bin/ed/ed.1 > ed.1.gz ===> bin/expr (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c expr.c cc1: warnings being treated as errors expr.c:812: warning: redundant redeclaration of 'yyparse' /usr/src/bin/expr/expr.y:77: warning: previous declaration of 'yyparse' was here *** [expr.o] Error code 1 Stop in /usr/src/bin/expr. *** [all] Error code 1 Stop in /usr/src/bin. *** [bin.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. 1(cage)# cd /usr -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 19:58: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B8F8AFF5 for ; Mon, 26 Aug 2013 19:58:23 +0000 (UTC) (envelope-from hskuhra@eumx.net) Received: from owm.eumx.net (eumx.net [91.82.101.43]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7110C2BB1 for ; Mon, 26 Aug 2013 19:58:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=eumx.net; h=date :message-id:from:to:cc:subject:in-reply-to:references :mime-version:content-type; s=default; bh=I+T2kpyjEylRfvPkD5UkiZ 9TSuk=; b=XCRNM9Si5X3zhCfbBIOSRK/Hiw1Y865ios9mWXwPc0O3a3U9yxBFVV 0QgML2eV3a2Ers4yvSUuf3qucDjN+E6Jvz9O5r1e2Hvg5fP2UNC7cQeCjt0oJUuT h5gueSeN3DbzTF36aSDdvRO9MM99FlOh6StRFlKHM4P6OIkhrBPS4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=eumx.net; h=date:message-id :from:to:cc:subject:in-reply-to:references:mime-version :content-type; q=dns; s=default; b=A144Ms9wOtggvF5uJ0Qi7WOLLo8+R 7fdd81OoRgGA4ITWWxN65+pH8BhUDFrV3aVkic6eM7YHJmND9E5LN3U1kNFc9sne /Vzt4YBBSEwLG30Ex4dz6zn8J1hMkI6C16+O8YvLrrEdt2KPqYXV4Fkk+J5HRQy9 16VjuygTP58OJY= Date: Mon, 26 Aug 2013 21:41:53 +0200 Message-ID: <86eh9gutmm.wl%hskuhra@eumx.net> From: "Herbert J. Skuhra" To: Mike Tancsa Subject: Re: RELENG_9 build error In-Reply-To: <521BA77E.3000603@sentex.net> References: <521BA77E.3000603@sentex.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.3.50 (i386-pc-freebsd9.2) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD-STABLE Mailing List 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, 26 Aug 2013 19:58:23 -0000 On Mon, 26 Aug 2013 15:07:42 -0400 Mike Tancsa wrote: > Does anyone have any idea how to correct this issue ? Already blew away > /usr/src and /usr/obj in case something got corrupted. I think I've resolved this issue by rebuilding and reinstalling yacc from /usr/src/usr.bin/yacc before running 'make buildworld'. -- Herbert From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 19:59:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5A5BF191 for ; Mon, 26 Aug 2013 19:59:20 +0000 (UTC) (envelope-from alonsoschaich@fastmail.fm) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2B7DC2BE3 for ; Mon, 26 Aug 2013 19:59:20 +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 AAED621098; Mon, 26 Aug 2013 15:59:13 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Mon, 26 Aug 2013 15:59:13 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mesmtp; bh=z+7XNPcFGUWppAbU2euK8alvUrc=; b=b/6cVLz4vVJkPHGCtZRj1LIGGH4H iNiZa721sJ/y187+LXqMl0LcahVyz4Cbh2Gr2e0T5syqjlnb/lyIotpkrBB5rLlZ jfv6olHhp07mE7e9UwvZ3jDqzeR9SeT4aN/aeoODS4/sVqYbgxU8Rwd6ZYYckXK/ /UsxGZ0Smm28H3I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :in-reply-to:references:mime-version:content-type :content-transfer-encoding; s=smtpout; bh=z+7XNPcFGUWppAbU2euK8a lvUrc=; b=Jw3XRDamzAp55bbOAYKeZHFdPiVac3ccyd79Rug57D/vNefe9zafp8 tudlIq8dfkHnzmX53ToEl2djawzIktGFQ5XbN9QhWw5JJtPxc+9IhDJyUmEqxVEY yKAzv7WpB2bzQAZPV1M4zUD6PiivnoX4Ym7BrZyLO4Hr3x0WcJfXc= X-Sasl-enc: Q9P+6cMYroYTt1xDcCaONPrvwWkREC0KbFRv1aZsQ1m1 1377547153 Received: from inet-0afeef15.localnet.edu (unknown [141.87.213.55]) by mail.messagingengine.com (Postfix) with ESMTPA id B01376800AE; Mon, 26 Aug 2013 15:59:12 -0400 (EDT) Date: Mon, 26 Aug 2013 21:59:11 +0200 From: Schaich Alonso To: Mike Tancsa Subject: Re: RELENG_9 build error Message-Id: <20130826215911.3b6044629ccc9908dd4b5dd6@fastmail.fm> In-Reply-To: <521BA77E.3000603@sentex.net> References: <521BA77E.3000603@sentex.net> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 19:59:20 -0000 On Mon, 26 Aug 2013 15:07:42 -0400 Mike Tancsa wrote: > > Does anyone have any idea how to correct this issue ? Already blew away > /usr/src and /usr/obj in case something got corrupted. > > Taking it you mean stable/9 by RELENG_9, it can be ``fixed'' by updating your sources, to any revision more recent than r254669 (which reverted the breaking commit) From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 20:02:43 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1121) id 2319F378; Mon, 26 Aug 2013 20:02:43 +0000 (UTC) Date: Mon, 26 Aug 2013 20:02:43 +0000 To: Thomas Mueller Subject: Re: Change in loader or kernel: won't boot with kfreebsd in grub2 Message-ID: <20130826200243.GA90837@hub.freebsd.org> References: <429990.38961.bm@smtp103.sbc.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <429990.38961.bm@smtp103.sbc.mail.bf1.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) From: nox@FreeBSD.ORG (Juergen Lock) Cc: "Andrey V. Elsukov" , freebsd-stable@freebsd.org, Juergen Lock 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, 26 Aug 2013 20:02:43 -0000 On Sun, Aug 25, 2013 at 03:35:06PM -0700, Thomas Mueller wrote: > > On Sat, Aug 24, 2013 at 08:53:31PM -0700, Thomas Mueller wrote: > > > Some updates: > > > > I could see what happens if I try to boot the FreeBSD boot partition on the hard drive using the Super Grub Disk with chainloader. > > > > If that works, it would boot FreeBSD 9.0-BETA1, but I would see if it works. > > > > That failed (invalid signature). > > > You probably need to chainload a freebsd-boot partition, _if_ you > > want to chainload at all. > > I was trying to chainload the freebsd-boot partition! But grub2 didn't like it. > Hmm I guess it doesn't know about that partition type yet then... > > > I could also try > > > kfreebsd /boot/kernel/kernel > > > > That failed to boot the proper partition, went to the debugger (db>), whereupon all I could type was "reboot". > > > You didn't get a mountroot prompt? If you did you can try typing a > > question mark and return, that should list possible partitions to mount > > root from. If you didn't, or you don't want to do this manually you > > need to set kFreeBSD.vfs.root.mountfrom=ufs:/dev/ada0p1 from grub2, > > or wherever your root partition is. > > I remember pressing a key, but then the system rushed past the mountroot prompt into the debugger prompt. > If you pressed return w/o typing anything I guess that's what will happen... > > > Now can I safely install boot into the partition to be booted, as I did with NetBSD on USB stick? > > > > gpart -p /boot/boot -i 3 > > > > That would be for /dev/ada0p3, but I am afraid of damaging something. > > > That would need to be on a freebsd-boot partition, and you want > > /boot/gptboot not /boot/boot. > > I believe bsdlabel can be used to install boot code to a partition, but believe that is not for GPT. Indeed. > I could try bsdlabel on a giant floppy image as I used installboot on a giant floppy image for NetBSD. > Uhm, why not just get grub2 kfreebsd booting working? Best, Juergen From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 20:12: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 463AE699 for ; Mon, 26 Aug 2013 20:12:40 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from nahkohe.jetcafe.org (nahkohe.jetcafe.org [205.147.26.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 283142CF8 for ; Mon, 26 Aug 2013 20:12:39 +0000 (UTC) X-Envelope-To: Received: from [205.147.26.5] (hokkshideh4.jetcafe.org [205.147.26.5]) by nahkohe.jetcafe.org (8.14.2/8.14.2) with ESMTP id r7QK16ZO075620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Aug 2013 13:01:07 -0700 (PDT) Message-ID: <521BB402.4000605@jetcafe.org> Date: Mon, 26 Aug 2013 13:01:06 -0700 From: Dave Hayes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121121 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: 9-STABLE, clang, and virtualbox 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, 26 Aug 2013 20:12:40 -0000 I've been trying to get emulators/virtualbox-ose-kmod to compile from ports on a clang built 9-STABLE: # uname -v FreeBSD 9.1-STABLE #0 r251391M: Tue Jun 4 09:47:42 PDT 2013 root@fb9build.jetcafe.org:/usr/obj/usr/src.amd64/sys/GENERIC amd64 # cc -v FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd9.1 Thread model: posix After some work I can get it to compile, but then I get this: # kldload /boot/modules/vboxdrv.ko kldload: can't load /boot/modules/vboxdrv.ko: Exec format error # dmesg | tail -2 KLD vboxdrv.ko: depends on kernel - not available or version mismatch linker_load_file: Unsupported file type # kldxref -d /boot/modules/vboxdrv.ko ... /boot/modules/vboxdrv.ko depends on kernel.901505 (901505,999999) module vboxdrv interface vboxdrv.1 # kldxref -d /boot/kernel | grep -C 3 /boot/kernel/kernel depends on kernel.901504 (901504,999999) module ppi_ppbus depends on ppbus.1 (1,1) /boot/kernel/kernel depends on kernel.901504 (901504,999999) module xpt depends on cam.1 (1,1) What's going on here and how can I debug this one? It seems that the module vboxdrv.ko has the correct versions. Thanks in advance for any assistance anyone can provide. :) -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< Imagination is not a talent of some men, but it is the health of every man. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 20:16:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8DC04800; Mon, 26 Aug 2013 20:16:24 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 64D2D2D30; Mon, 26 Aug 2013 20:16:24 +0000 (UTC) Received: from glenbarber.us (unknown [IPv6:2001:470:8:1205:701e:d184:9d94:ba66]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id A1E562F24; Mon, 26 Aug 2013 20:16:22 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us A1E562F24 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Mon, 26 Aug 2013 16:16:20 -0400 From: Glen Barber To: Dave Hayes Subject: Re: 9-STABLE, clang, and virtualbox Message-ID: <20130826201620.GF49310@glenbarber.us> References: <521BB402.4000605@jetcafe.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0qt3EE9wi45a2ZFX" Content-Disposition: inline In-Reply-To: <521BB402.4000605@jetcafe.org> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 20:16:24 -0000 --0qt3EE9wi45a2ZFX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 26, 2013 at 01:01:06PM -0700, Dave Hayes wrote: > I've been trying to get emulators/virtualbox-ose-kmod to compile > from ports on a clang built 9-STABLE: >=20 > # uname -v > FreeBSD 9.1-STABLE #0 r251391M: Tue Jun 4 09:47:42 PDT 2013 > root@fb9build.jetcafe.org:/usr/obj/usr/src.amd64/sys/GENERIC amd64 > # cc -v > FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 > Target: x86_64-unknown-freebsd9.1 > Thread model: posix >=20 > After some work I can get it to compile, but then I get this: >=20 > # kldload /boot/modules/vboxdrv.ko > kldload: can't load /boot/modules/vboxdrv.ko: Exec format error > # dmesg | tail -2 > KLD vboxdrv.ko: depends on kernel - not available or version mismatch > linker_load_file: Unsupported file type > # kldxref -d /boot/modules/vboxdrv.ko > ... > /boot/modules/vboxdrv.ko > depends on kernel.901505 (901505,999999) > module vboxdrv > interface vboxdrv.1 > # kldxref -d /boot/kernel | grep -C 3 /boot/kernel/kernel > depends on kernel.901504 (901504,999999) > module ppi_ppbus > depends on ppbus.1 (1,1) > /boot/kernel/kernel > depends on kernel.901504 (901504,999999) > module xpt > depends on cam.1 (1,1) >=20 > What's going on here and how can I debug this one? It seems that the > module vboxdrv.ko has the correct versions. >=20 > Thanks in advance for any assistance anyone can provide. :) What is the svn revision of your /usr/src/ checkout? Glen --0qt3EE9wi45a2ZFX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBCAAGBQJSG7eUAAoJEFJPDDeguUajSnMH/RgZ0QWxAwEPrrZ1kyAB+YVU eeWvwQWAgkXQ11JAtJMGO1Dh3HnPycJF8gtvLr4OplgmOycS6dSILEi/yCKHJSLE aDj/TGT+GxzfeKMUvSLMh3VxD85Cj/Fy/k0EaBMfC2kWTvpmbML5FGr85gJXa8aF 4fUfFJxQ1E1FeM2qCHOkYdw3ptOKvjIr92HUVBghmdy4TpbaYeMN6RPdEDw6R0af cF18KcpOaHfXAKBuLsiFMAzkA/ilcw28rKO52huvLeNuFNQG+K18FI0Z/AygX/Ba GoElkjlHbFYumr1e2t2g4K7kuobc89976f4cJUAuZx9WtWA6OBi7mCd2mP4CEW0= =ryAV -----END PGP SIGNATURE----- --0qt3EE9wi45a2ZFX-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 21:11:07 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 63A828AD for ; Mon, 26 Aug 2013 21:11:07 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1ACF62104 for ; Mon, 26 Aug 2013 21:11:07 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.7/8.14.5) with ESMTP id r7QLB4sk098002; Mon, 26 Aug 2013 17:11:04 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <521BC466.3030400@sentex.net> Date: Mon, 26 Aug 2013 17:11:02 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Schaich Alonso Subject: Re: RELENG_9 build error References: <521BA77E.3000603@sentex.net> <20130826215911.3b6044629ccc9908dd4b5dd6@fastmail.fm> In-Reply-To: <20130826215911.3b6044629ccc9908dd4b5dd6@fastmail.fm> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 on 64.7.153.18 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 21:11:07 -0000 On 8/26/2013 3:59 PM, Schaich Alonso wrote: > On Mon, 26 Aug 2013 15:07:42 -0400 > Mike Tancsa wrote: > >> >> Does anyone have any idea how to correct this issue ? Already blew away >> /usr/src and /usr/obj in case something got corrupted. >> >> > > Taking it you mean stable/9 by RELENG_9, it can be ``fixed'' by updating your > sources, to any revision more recent than r254669 (which reverted the breaking > commit) Actually, I had done that. The correct solution was to rebuild and install yacc first (as suggested by Herbert), as I was running FreeBSD 9.2-PRERELEASE #0 r254663 So the bogus yacc was installed and I needed to clobber that. ---Mike > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 21:16: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BE4A7B6F for ; Mon, 26 Aug 2013 21:16:05 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 85847213B for ; Mon, 26 Aug 2013 21:16:05 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEADrEG1KDaFve/2dsb2JhbABaDoN/gye8fYE4dIIkAQEEASNWBRYOCgICDRkCWQaIDgalVZI7gSmOBh14NAeCaIExA6lPgl9bIIEuBxci X-IronPort-AV: E=Sophos;i="4.89,962,1367985600"; d="scan'208";a="47502277" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 26 Aug 2013 17:15:59 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 4FD01B4032; Mon, 26 Aug 2013 17:15:59 -0400 (EDT) Date: Mon, 26 Aug 2013 17:15:59 -0400 (EDT) From: Rick Macklem To: Daniel Braniss Message-ID: <2024786487.13891803.1377551759314.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: another? NFS deadlock on 9.2-PRERELEASE MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) 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, 26 Aug 2013 21:16:05 -0000 Daniel Braniss wrote: > I upgraded our web server, and only after 3 hours it hung :-( > (as a side note, I have 2 other web servers, also running 9.2 doing > great :-) > go figure. > > anyways, in > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/0 > > is the info after a forced panic. > Looks like the same hang to me. Several threads are sleeping on "pgrbwt" and lots are waiting for an NFS vnode lock. It should be fixed in RC3 (or revert r250907). If it still hangs with RC3 (or r250907 reverted), email again. rick > my guts say its running out of resources - mainly network related, > but > can't pinpoint it. > > any help will be most welcomed > > cheers, > danny > > > > > From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 21:16:41 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 84DECC77; Mon, 26 Aug 2013 21:16:41 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from nahkohe.jetcafe.org (nahkohe.jetcafe.org [205.147.26.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 64F58214E; Mon, 26 Aug 2013 21:16:41 +0000 (UTC) X-Envelope-To: freebsd-stable@FreeBSD.org Received: from [205.147.26.5] (hokkshideh4.jetcafe.org [205.147.26.5]) by nahkohe.jetcafe.org (8.14.2/8.14.2) with ESMTP id r7QLGe6M076819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Aug 2013 14:16:40 -0700 (PDT) Message-ID: <521BC5B7.4020007@jetcafe.org> Date: Mon, 26 Aug 2013 14:16:39 -0700 From: Dave Hayes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121121 Thunderbird/16.0.2 MIME-Version: 1.0 To: Glen Barber Subject: Re: 9-STABLE, clang, and virtualbox References: <521BB402.4000605@jetcafe.org> <20130826201620.GF49310@glenbarber.us> In-Reply-To: <20130826201620.GF49310@glenbarber.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 21:16:41 -0000 On 08/26/13 13:16, Glen Barber wrote: > On Mon, Aug 26, 2013 at 01:01:06PM -0700, Dave Hayes wrote: >> I've been trying to get emulators/virtualbox-ose-kmod to compile >> from ports on a clang built 9-STABLE: >> >> # uname -v >> FreeBSD 9.1-STABLE #0 r251391M: Tue Jun 4 09:47:42 PDT 2013 ^^^^^^^^ >> root@fb9build.jetcafe.org:/usr/obj/usr/src.amd64/sys/GENERIC amd64 >> # cc -v >> FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 >> Target: x86_64-unknown-freebsd9.1 >> Thread model: posix >> >> After some work I can get it to compile, but then I get this: >> >> # kldload /boot/modules/vboxdrv.ko >> kldload: can't load /boot/modules/vboxdrv.ko: Exec format error >> # dmesg | tail -2 >> KLD vboxdrv.ko: depends on kernel - not available or version mismatch >> linker_load_file: Unsupported file type >> # kldxref -d /boot/modules/vboxdrv.ko >> ... >> /boot/modules/vboxdrv.ko >> depends on kernel.901505 (901505,999999) >> module vboxdrv >> interface vboxdrv.1 >> # kldxref -d /boot/kernel | grep -C 3 /boot/kernel/kernel >> depends on kernel.901504 (901504,999999) >> module ppi_ppbus >> depends on ppbus.1 (1,1) >> /boot/kernel/kernel >> depends on kernel.901504 (901504,999999) >> module xpt >> depends on cam.1 (1,1) >> >> What's going on here and how can I debug this one? It seems that the >> module vboxdrv.ko has the correct versions. >> >> Thanks in advance for any assistance anyone can provide. :) > > What is the svn revision of your /usr/src/ checkout? 251391. See the uname above. :) -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< A question about the sky -- The answer about a rope. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 21:21:17 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 16D66DBD; Mon, 26 Aug 2013 21:21:17 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E0EFC21A6; Mon, 26 Aug 2013 21:21:16 +0000 (UTC) Received: from glenbarber.us (unknown [IPv6:2001:470:8:1205:701e:d184:9d94:ba66]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 166FC2594; Mon, 26 Aug 2013 21:21:15 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 166FC2594 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Mon, 26 Aug 2013 17:21:13 -0400 From: Glen Barber To: Dave Hayes Subject: Re: 9-STABLE, clang, and virtualbox Message-ID: <20130826212113.GG49310@glenbarber.us> References: <521BB402.4000605@jetcafe.org> <20130826201620.GF49310@glenbarber.us> <521BC5B7.4020007@jetcafe.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2oox5VnwalALFvA7" Content-Disposition: inline In-Reply-To: <521BC5B7.4020007@jetcafe.org> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 21:21:17 -0000 --2oox5VnwalALFvA7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 26, 2013 at 02:16:39PM -0700, Dave Hayes wrote: > On 08/26/13 13:16, Glen Barber wrote: > >On Mon, Aug 26, 2013 at 01:01:06PM -0700, Dave Hayes wrote: > >>I've been trying to get emulators/virtualbox-ose-kmod to compile > >>from ports on a clang built 9-STABLE: > >> > >> # uname -v > >> FreeBSD 9.1-STABLE #0 r251391M: Tue Jun 4 09:47:42 PDT 2013 > ^^^^^^^^ > >>root@fb9build.jetcafe.org:/usr/obj/usr/src.amd64/sys/GENERIC amd64 > >> # cc -v > >> FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 > >> Target: x86_64-unknown-freebsd9.1 > >> Thread model: posix > >> > >>After some work I can get it to compile, but then I get this: > >> > >> # kldload /boot/modules/vboxdrv.ko > >> kldload: can't load /boot/modules/vboxdrv.ko: Exec format error > >> # dmesg | tail -2 > >> KLD vboxdrv.ko: depends on kernel - not available or version mismatch > >> linker_load_file: Unsupported file type > >> # kldxref -d /boot/modules/vboxdrv.ko > >> ... > >> /boot/modules/vboxdrv.ko > >> depends on kernel.901505 (901505,999999) > >> module vboxdrv > >> interface vboxdrv.1 > >> # kldxref -d /boot/kernel | grep -C 3 /boot/kernel/kernel > >> depends on kernel.901504 (901504,999999) > >> module ppi_ppbus > >> depends on ppbus.1 (1,1) > >> /boot/kernel/kernel > >> depends on kernel.901504 (901504,999999) > >> module xpt > >> depends on cam.1 (1,1) > >> > >>What's going on here and how can I debug this one? It seems that the > >>module vboxdrv.ko has the correct versions. > >> > >>Thanks in advance for any assistance anyone can provide. :) > > > >What is the svn revision of your /usr/src/ checkout? >=20 > 251391. See the uname above. :) That does not mean your current checkout matches that revision. Glen --2oox5VnwalALFvA7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBCAAGBQJSG8bJAAoJEFJPDDeguUajCbkIAIBoguNTOzcg1tmkPK0OqAs8 p4J58aUYay2DCIsy/A4TKkvYQOdLA0Snh/vkbR3h+xKcUafacB+CMk3P2fG9GKLm 1yy4UX97TddNQqVLFAjFww/Um/MfOAuXidSxXiRad4U0SiiX1NfPp3is5IGzvIWz ZWHpdCYIPjYNoUjZO4JVBkxSjVKx2Sy5yZfz5IQ/FBSZQoEQ6rd5uBGWfnGrFvcc fo0UmOzY1+I3roQxJYCY1jDuhjV1j8qwasy6tEA3HQx6IVBKo0v08/H+7TwoEOW7 DOHELNIX6Qb4GKXEWWsKTc4J+TEiLjVeaezpn9B83vsnaYWZJLcQuVEzQEEwoVQ= =OzFf -----END PGP SIGNATURE----- --2oox5VnwalALFvA7-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 21:29:31 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E3AD4FB2; Mon, 26 Aug 2013 21:29:31 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from nahkohe.jetcafe.org (nahkohe.jetcafe.org [205.147.26.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A75A6220A; Mon, 26 Aug 2013 21:29:31 +0000 (UTC) X-Envelope-To: freebsd-stable@FreeBSD.org Received: from [205.147.26.5] (hokkshideh4.jetcafe.org [205.147.26.5]) by nahkohe.jetcafe.org (8.14.2/8.14.2) with ESMTP id r7QLTULD077062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Aug 2013 14:29:30 -0700 (PDT) Message-ID: <521BC8BA.7070603@jetcafe.org> Date: Mon, 26 Aug 2013 14:29:30 -0700 From: Dave Hayes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121121 Thunderbird/16.0.2 MIME-Version: 1.0 To: Glen Barber Subject: Re: 9-STABLE, clang, and virtualbox References: <521BB402.4000605@jetcafe.org> <20130826201620.GF49310@glenbarber.us> <521BC5B7.4020007@jetcafe.org> <20130826212113.GG49310@glenbarber.us> In-Reply-To: <20130826212113.GG49310@glenbarber.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 21:29:32 -0000 On 08/26/13 14:21, Glen Barber wrote: > On Mon, Aug 26, 2013 at 02:16:39PM -0700, Dave Hayes wrote: >> On 08/26/13 13:16, Glen Barber wrote: >>> On Mon, Aug 26, 2013 at 01:01:06PM -0700, Dave Hayes wrote: >>>> I've been trying to get emulators/virtualbox-ose-kmod to compile >>> >from ports on a clang built 9-STABLE: >>>> >>>> # uname -v >>>> FreeBSD 9.1-STABLE #0 r251391M: Tue Jun 4 09:47:42 PDT 2013 >> ^^^^^^^^ >>>> root@fb9build.jetcafe.org:/usr/obj/usr/src.amd64/sys/GENERIC amd64 >>>> # cc -v >>>> FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 >>>> Target: x86_64-unknown-freebsd9.1 >>>> Thread model: posix >>>> >>>> After some work I can get it to compile, but then I get this: >>>> >>>> # kldload /boot/modules/vboxdrv.ko >>>> kldload: can't load /boot/modules/vboxdrv.ko: Exec format error >>>> # dmesg | tail -2 >>>> KLD vboxdrv.ko: depends on kernel - not available or version mismatch >>>> linker_load_file: Unsupported file type >>>> # kldxref -d /boot/modules/vboxdrv.ko >>>> ... >>>> /boot/modules/vboxdrv.ko >>>> depends on kernel.901505 (901505,999999) >>>> module vboxdrv >>>> interface vboxdrv.1 >>>> # kldxref -d /boot/kernel | grep -C 3 /boot/kernel/kernel >>>> depends on kernel.901504 (901504,999999) >>>> module ppi_ppbus >>>> depends on ppbus.1 (1,1) >>>> /boot/kernel/kernel >>>> depends on kernel.901504 (901504,999999) >>>> module xpt >>>> depends on cam.1 (1,1) >>>> >>>> What's going on here and how can I debug this one? It seems that the >>>> module vboxdrv.ko has the correct versions. >>>> >>>> Thanks in advance for any assistance anyone can provide. :) >>> >>> What is the svn revision of your /usr/src/ checkout? >> >> 251391. See the uname above. :) > > That does not mean your current checkout matches that revision. In my case it does....I checked with svn info before I sent the mail. -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< Only one who is seeking certainty can be uncertain. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 26 23:12:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BC77AD8A for ; Mon, 26 Aug 2013 23:12:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 80FAB27CD for ; Mon, 26 Aug 2013 23:12:01 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMEAFbgG1KDaFve/2dsb2JhbABagzxRgye8fIE4dIIkAQEBAwEBAQEgKyALGxgCAg0ZAikBCSYGCAcEARwEh1oGDKVMkjqBKY4VgQUBMweCaIExA5Ulg3aQNIM6IDKBAzk X-IronPort-AV: E=Sophos;i="4.89,962,1367985600"; d="scan'208";a="47519788" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 26 Aug 2013 19:11:48 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 7E4EEB3F62; Mon, 26 Aug 2013 19:11:48 -0400 (EDT) Date: Mon, 26 Aug 2013 19:11:48 -0400 (EDT) From: Rick Macklem To: Matthias Schuendehuette Message-ID: <1524261611.13937235.1377558708504.JavaMail.root@uoguelph.ca> In-Reply-To: <1EFE239F82F279488E86A61C92D5E2DE03828F@DENBGAT9EI2MSX.ww902.siemens.net> Subject: Re: Stack overflow with kernel r254683 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 23:12:02 -0000 Matthias Schuendehuette wrote: > Hello, >=20 > yesterday I got a kernel crash on my server (a ProLiant DL380 G5): >=20 > "panic: stack overflow detected; backtrace may be corrupted" >=20 > Kernel is "9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #7 r254683" >=20 >=20 > The stack trace reads: >=20 > #0 doadump (textdump=3D1) at pcpu.h:249 > 249 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=3D1) at pcpu.h:249 > #1 0xc0668a4d in kern_reboot (howto=3D260) > at /usr/src/sys/kern/kern_shutdown.c:449 > #2 0xc0668f07 in panic (fmt=3D0x104
) > at /usr/src/sys/kern/kern_shutdown.c:637 > #3 0xc0691da2 in __stack_chk_fail () > at /usr/src/sys/kern/stack_protector.c:17 > #4 0xc7fdb175 in nfsrvd_setattr (nd=3D0xc73b4400, isdgram=3D-952596480, > vp=3D0xc8001140, p=3D0xf405ecc8, exp=3D0xc07af7f0) > at > /usr/src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdserv.c:371 > #5 0xc7fdb6e0 in nfsrvd_releaselckown (nd=3D0xc7442a00, > isdgram=3D-952596480, > vp=3D0xc7388848, p=3D0xf405ecb8, exp=3D0x0) > at > /usr/src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdserv.c:3481 > #6 0xc07af7f0 in svc_run_internal (pool=3D0xc7de8b80, ismaster=3D0) > at /usr/src/sys/rpc/svc.c:1109 > #7 0xc07b006d in svc_thread_start (arg=3D0xc7de8b80) > at /usr/src/sys/rpc/svc.c:1200 > #8 0xc06384f7 in fork_exit (callout=3D0xc07b0060 , > arg=3D0xc7de8b80, frame=3D0xf405ed08) at > /usr/src/sys/kern/kern_fork.c:992 > #9 0xc08787c4 in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:279 >=20 Well, when I've looked on i386, the nfsd threads normally don't use 1 page and the stacks are 2 pages, so I doubt an nfsd thread is blowing the stack. Also, nfsrvd_releaselckown() doesn't call nfsrvd_setattr(), so the backtrac= e doesn't make much sense. Afraid I can't help more than this. Good luck with it, rick >=20 > I have all the files in /var/crash, so if someone wants additional > informations > I should be able to deliver them. >=20 > The kernel config file is customized in the sense that I have removed > kernel items, that aren't used on that machine. >=20 > One major difference: I use >=20 > < options NFSCLIENT # Network Filesystem Client > < options NFSSERVER # Network Filesystem Server >=20 > instead of >=20 > > options NFSCL # New Network Filesystem > > Client > > options NFSD # New Network Filesystem > > Server >=20 > because a kernel a few weeks ago immediately crashed with the new > NFS-code. >=20 > But it seems now, that the old NFS-code is also somehow damaged. >=20 > Ah, and I still have from older releases of FreeBSD the following > loader options - do they still make sense? >=20 > geom_vinum_load=3D"YES" > kern.maxdsiz=3D"734003200" > vm.pmap.shpgperproc=3D256 > vm.pmap.pv_entry_max=3D3145728 >=20 >=20 > 'geom_vinum' is used as LVM only, no RAIDs are configured. >=20 > This server is primarily a Samba server with the SMB-shares exported > as NFS-shares as well > for the other *nix-servers around. >=20 > Because this is the most loaded production server, testing is a bit > difficult, restricted to the evening and the weekends. >=20 > On my two other FreeBSD machines I have no problems at all, one of > them is an identical ProLiant server with a nearly identical kernel > config - runs like a charm... >=20 > Has someone a good advice or further questions? >=20 >=20 > =20 > with best regards > Matthias Sch=C3=BCndeh=C3=BCtte >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" >=20 From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 01:42:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 32F5AC34 for ; Tue, 27 Aug 2013 01:42:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1EF2FB2 for ; Tue, 27 Aug 2013 01:42:01 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r7R1fs2X017228; Tue, 27 Aug 2013 04:41:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r7R1fs2X017228 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r7R1fsM0017227; Tue, 27 Aug 2013 04:41:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 27 Aug 2013 04:41:54 +0300 From: Konstantin Belousov To: Rick Macklem Subject: Re: Stack overflow with kernel r254683 Message-ID: <20130827014154.GO4972@kib.kiev.ua> References: <1EFE239F82F279488E86A61C92D5E2DE03828F@DENBGAT9EI2MSX.ww902.siemens.net> <1524261611.13937235.1377558708504.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0L3On4CPY00n7Jtc" Content-Disposition: inline In-Reply-To: <1524261611.13937235.1377558708504.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-stable@freebsd.org, Matthias Schuendehuette 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, 27 Aug 2013 01:42:03 -0000 --0L3On4CPY00n7Jtc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 26, 2013 at 07:11:48PM -0400, Rick Macklem wrote: > Matthias Schuendehuette wrote: > > Hello, > >=20 > > yesterday I got a kernel crash on my server (a ProLiant DL380 G5): > >=20 > > "panic: stack overflow detected; backtrace may be corrupted" > >=20 > > Kernel is "9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #7 r254683" > >=20 > >=20 > > The stack trace reads: > >=20 > > #0 doadump (textdump=3D1) at pcpu.h:249 > > 249 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) #0 doadump (textdump=3D1) at pcpu.h:249 > > #1 0xc0668a4d in kern_reboot (howto=3D260) > > at /usr/src/sys/kern/kern_shutdown.c:449 > > #2 0xc0668f07 in panic (fmt=3D0x104
) > > at /usr/src/sys/kern/kern_shutdown.c:637 > > #3 0xc0691da2 in __stack_chk_fail () > > at /usr/src/sys/kern/stack_protector.c:17 > > #4 0xc7fdb175 in nfsrvd_setattr (nd=3D0xc73b4400, isdgram=3D-952596480, > > vp=3D0xc8001140, p=3D0xf405ecc8, exp=3D0xc07af7f0) > > at > > /usr/src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdserv.c:371 > > #5 0xc7fdb6e0 in nfsrvd_releaselckown (nd=3D0xc7442a00, > > isdgram=3D-952596480, > > vp=3D0xc7388848, p=3D0xf405ecb8, exp=3D0x0) > > at > > /usr/src/sys/modules/nfsd/../../fs/nfsserver/nfs_nfsdserv.c:3481 > > #6 0xc07af7f0 in svc_run_internal (pool=3D0xc7de8b80, ismaster=3D0) > > at /usr/src/sys/rpc/svc.c:1109 > > #7 0xc07b006d in svc_thread_start (arg=3D0xc7de8b80) > > at /usr/src/sys/rpc/svc.c:1200 > > #8 0xc06384f7 in fork_exit (callout=3D0xc07b0060 , > > arg=3D0xc7de8b80, frame=3D0xf405ed08) at > > /usr/src/sys/kern/kern_fork.c:992 > > #9 0xc08787c4 in fork_trampoline () at > > /usr/src/sys/i386/i386/exception.s:279 > >=20 > Well, when I've looked on i386, the nfsd threads normally don't use 1 page > and the stacks are 2 pages, so I doubt an nfsd thread is blowing the stac= k. It is overflowing the frame, not the whole stack. In other word, something overwrote the canary which was put on the stack between local variables and the return address, possibly corrupting the return address as well. > Also, nfsrvd_releaselckown() doesn't call nfsrvd_setattr(), so the backtr= ace > doesn't make much sense. Yes, this might be one of the consequences of the stack smashing. >=20 > Afraid I can't help more than this. Good luck with it, rick >=20 > >=20 > > I have all the files in /var/crash, so if someone wants additional > > informations > > I should be able to deliver them. > >=20 > > The kernel config file is customized in the sense that I have removed > > kernel items, that aren't used on that machine. > >=20 > > One major difference: I use > >=20 > > < options NFSCLIENT # Network Filesystem Client > > < options NFSSERVER # Network Filesystem Server > >=20 > > instead of > >=20 > > > options NFSCL # New Network Filesystem > > > Client > > > options NFSD # New Network Filesystem > > > Server > >=20 > > because a kernel a few weeks ago immediately crashed with the new > > NFS-code. > >=20 > > But it seems now, that the old NFS-code is also somehow damaged. > >=20 > > Ah, and I still have from older releases of FreeBSD the following > > loader options - do they still make sense? > >=20 > > geom_vinum_load=3D"YES" > > kern.maxdsiz=3D"734003200" > > vm.pmap.shpgperproc=3D256 > > vm.pmap.pv_entry_max=3D3145728 > >=20 > >=20 > > 'geom_vinum' is used as LVM only, no RAIDs are configured. > >=20 > > This server is primarily a Samba server with the SMB-shares exported > > as NFS-shares as well > > for the other *nix-servers around. > >=20 > > Because this is the most loaded production server, testing is a bit > > difficult, restricted to the evening and the weekends. > >=20 > > On my two other FreeBSD machines I have no problems at all, one of > > them is an identical ProLiant server with a nearly identical kernel > > config - runs like a charm... > >=20 > > Has someone a good advice or further questions? > >=20 > >=20 > > =20 > > with best regards > > Matthias Sch??ndeh??tte > >=20 > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to > > "freebsd-stable-unsubscribe@freebsd.org" > >=20 > _______________________________________________ > 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" --0L3On4CPY00n7Jtc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSHAPhAAoJEJDCuSvBvK1B/E0P/0tgoAk0Yeiouk8mSSLKN/1A Gyk60vdh4fxgbjrMNWIi+3R5/ZvmnpZkFAH5pVpnblhKqC0WqGgxoUKibhGKnyul fGshMLRZMkSU+YAzee1h/agDGnUHkxR0LqRHib21Q9puC2jjZETm6xqwpm6kRlrc M1SSS8nt7pSJG9xqcNDfOTa7EOa0ucgob/SyLcilOnOHrAhAFWKQp5v2qie55XaK VL/yKlyCGmDt9u970yDgzBjADt3J8V1ErmsZA7SK9yi2W2Gj/5ENdfnRFqOAGDpm UMfS9THi7uEizTrC2wkpFtwN9lhgzR6uYI2qGTEOMoHtcHkF+ZdUNHbd83zc/bzS Nz25EFxtrC5BUdwaTCC2nST7wjz8/iawG2GQz3GQT23w+ozrPUPCxfyB26GtU8G2 9//uDF2EWph1KCeaHljT0EBCcIjcyTnug+DGP80RxOAaVzBxB6dCvu31aVL4H4/3 ugUneqfc2ymMHUFNPOteWYp+Ok6BsPG+s+Jy9+JolDV14FV9fUr1q6s2PEuyMgp1 aBd7pTC62Z9JP0YynknpMpQRhYg9MFdoP6y0NRi0ORvvasKUwtHaP0e/KotI0oLI LfhY5p+DPyR1LAZaPWg5KsCzPucHLowHir8u42DPEye31xl1ki32OE+89nwZ1ZLK KdbrVDw08jH9mPVFIQtX =2rTd -----END PGP SIGNATURE----- --0L3On4CPY00n7Jtc-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 04:26: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 082D7B5F; Tue, 27 Aug 2013 04:26:11 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (torment.daemoninthecloset.org [94.242.209.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E07F28B4; Tue, 27 Aug 2013 04:26:10 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id 9865C42C2632; Tue, 27 Aug 2013 06:24:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Virus-Scanned: amavisd-new at daemoninthecloset.org Date: Mon, 26 Aug 2013 23:18:37 -0500 (CDT) From: Bryan Venteicher To: Harald Schmalzbauer Message-ID: <1117188271.19176.1377577117350.JavaMail.root@daemoninthecloset.org> In-Reply-To: <5214D37F.5000307@omnilan.de> References: <601099152.721.1375661537866.JavaMail.root@daemoninthecloset.org> <5214D37F.5000307@omnilan.de> Subject: Re: [CFT] VMware vmxnet3 ethernet driver MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [192.168.10.20] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - GC20 ([unknown])/8.0.2_GA_5569) Thread-Topic: VMware vmxnet3 ethernet driver Thread-Index: wVc2YFjrnum8ylaZxy8pLzcODD7JCg== Cc: FreeBSD Stable , current@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, 27 Aug 2013 04:26:11 -0000 ----- Original Message ----- > Bez=C3=BCglich Bryan Venteicher's Nachricht vom 05.08.2013 02:12 (localti= me): > > Hi, > > > > I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a > > lot of cleanup, bug fixes, new features, etc (+2000 new lines) along > > the way so there is not much of a resemblance left. > > > > The driver is in good enough shape I'd like additional testers. A patch > > against -CURRENT is at [1]. Alternatively, the driver and a Makefile is > > at [2]; this should compile at least as far back as 9.1. I can look at > > 8-STABLE if there is interest. > > > > Obviously, besides reports of 'it works', I'm interested performance vs > > the emulated e1000, and (for those using it) the VMware tools vmxnet3 > > driver. Hopefully it is no worse :) >=20 > Hello Bryan, >=20 > thanks a lot for your hard work! >=20 > It seems if_vmx doesn't support jumbo frames. If I set mtu 9000, I get > =C2=BBvmx0: cannot populate Rx queue 0=C2=AB, I have no problems using ju= mbo > frames with vmxnet3. >=20 This could fail for two reasons - could not allocate an mbuf cluster, or the call to bus_dmamap_load_mbuf_sg() failed. For the former, you should check vmstat -z. For the later, the behavior of bus_dmamap_load_mbuf= _sg() changed between 9.1 and 9.2, and I know it was broken for awhile. I don't recall exactly when I fixed it (I think shortly after I made the original announcement). Could you retry with the files from HEAD @ [1]? Also, there are new sysctl oids (dev.vmx.X.mbuf_load_failed & dev.vmx.X.mgetcl_failed) for these errors. I just compiled the driver on 9.2-RC2 with the sources from HEAD and was able to change the MTU to 9000. [1]- http://svnweb.freebsd.org/base/head/sys/dev/vmware/vmxnet3/ > I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ESXi > 5.1U1 and FreeBSD-9.2-RC2 > Two guests are connected to one MTU9000 "VMware Software Switch". >=20 I've got a few performance things to still look at. What's the sysctl=20 dev.vmx.X output for the if_vmx<->if_vmx tests? > Simple iperf (standard TCP) results: >=20 > vmxnet3jumbo <-> vmxnet3jumbo > 5.3Gbits/sec, load: 40-60%Sys 0.5-2%Intr >=20 > vmxnet3 <-> vmxnet3 > 1.85 GBits/sec, load: 60-80%Sys 0-0.8%Intr >=20 >=20 > if_vmx <-> if_vmx > 1.51 GBits/sec, load: 10-45%Sys 40-48%Intr > !!! > if_vmxjumbo <-> if_vmxjumbo not possible >=20 >=20 > if_em(e1000) <-> if_em(e1000) > 1.23 GBits/sec, load: 80-60%Sys 0.5-8%Intr >=20 > if_em(e1000)jumbo <-> if_em(e1000)jumbo > 2.27Gbits/sec, load: 40-30%Sys 0.5-5%Intr >=20 >=20 > if_igb(e1000e)junmbo <-> if_igb(e1000e)jumbo > 5.03 Gbits/s, load: 70-60%Sys 0.5%Intr >=20 > if_igb(e1000e) <-> if_igb(e1000e) > 1.39 Gbits/s, load: 60-80%Sys 0.5%Intr >=20 >=20 > f_igb(e1000e) <-> if_igb(e1000e), both hw.em.[rt]xd=3D4096 > 1.66 Gbits/s, load: 65-90%Sys 0.5%Intr >=20 > if_igb(e1000e)junmbo <-> if_igb(e1000e)jumbo, both hw.em.[rt]xd=3D4096 > 4.81 Gbits/s, load: 65%Sys 0.5%Intr >=20 > Conclusion: > if_vmx performs well compared to the regular emulated nics and standard > MTU, but it's behind tuned e1000e nic emulation and can't reach vmxnet3 > performance with regular mtu. If one needs throughput, the missing jumbo > frame support in if_vmx is a show stopper. >=20 > e1000e is preferable over e1000, even if not officially choosable with > "FreeBSD"-selection as guest (edit .vmx and alter ethernet0.virtualDev = =3D > "e1000e", and dont forget to set hw.em.enable_msix=3D0 in loader.conf, > although the driver e1000e attaches is if_igb!) >=20 > Thanks, >=20 > -Harry >=20 > From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 04:51:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BFAB5EA for ; Tue, 27 Aug 2013 04:51:39 +0000 (UTC) (envelope-from mailreturn@smtp.ymlp46.net) Received: from smtp.ymlp46.net (smtp.ymlp46.net [85.158.212.102]) by mx1.freebsd.org (Postfix) with SMTP id A5FC62A10 for ; Tue, 27 Aug 2013 04:51:38 +0000 (UTC) Received: (qmail 16210 invoked by uid 0); 27 Aug 2013 04:51:30 -0000 Date: Tue, 27 Aug 2013 06:51:30 +0200 To: freebsd-stable@freebsd.org From: classement des imprimeries en ligne Subject: Vos nouveaux tarifs "panneaux Akilux" et impression brochures Message-ID: <6a56807cda37f8a7d7d7fa62712671ba@smtp.ymlp46.net> X-YMLPcode: g904+2673+128498 MIME-Version: 1.0 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: imprimeurenligne@leclassement.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 04:51:39 -0000 --------------------------------------------------------------------------= ------ Cette newsletter vous a =C3=A9t=C3=A9 envoy=C3=A9e au format graphique = HTML. Si vous lisez cette version, alors votre logiciel de messagerie = pr=C3=A9f=C3=A8re les e-mails au format texte. Vous pouvez lire la version originale en ligne: http://ymlp225.net/z2Sppv --------------------------------------------------------------------------= ------ Nouveaux tarifs panneaux akilux, livraison gratuite Acceder directement sur le site=C2=A0 ( http://www.flyers.entreprise-com.fr/page/61676 ) Nous proposons tous les formats et decoupes e personnalis=C3=A9es sur demande =C2=A0 T=C3=A9l=C3=A9charger tout les tarifs en PDF ( http://www.flyers.entreprise-com.fr/upload/21juin/tarifs_akilux_septembre_= 2013.pdf ) =C2=A0 =C2=A0Tarifs panneaux akilux sans oeillet =C2=A0=C2=A0Panneaux=C2=A030x40=C2=A0 =C2=A0 =C2=A0 Panneau 40x60 =C2=A0 =C2=A0 =C2=A0Panneau 60x80 =C2=A0 R=C2=B0 =C2=A0 =C2=A0 R=C2=B0V=C2=B0 =C2=A0=C2=A0 R=C2=B0 =C2=A0 =C2=A0=C2=A0 R=C2=B0/V=C2=B0 R=C2=B0 =C2=A0 =C2=A0 R=C2=B0V=C2=B0 =C2=A0 2 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 22 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 23 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 23 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 25 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 26 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 30 =E2=82=AC 4 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 24 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 27 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 27 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 31 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 33 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 40 =E2=82=AC 6 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 27 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 31 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 31 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 36 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 40 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 50 =E2=82=AC 8 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 29 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 34 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 34 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 42 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 46 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 60 =E2=82=AC 10 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 32 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 38 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 38 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 48 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 53 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 70 =E2=82=AC 15 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 38 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 48 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 48 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 62 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 70 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 95 =E2=82=AC 20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 44 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 57 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 57 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 76 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 87 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 116 =E2=82=AC 30 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 57 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 76 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 76 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 100 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 116 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 146 =E2=82=AC 35 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 63 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 85 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 85 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 113 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 132 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 170 =E2=82=AC 40 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 69 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 94 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 94 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 127 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 140 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 194 =E2=82=AC 50 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 82 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 109 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 109 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 135 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 162 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 233 =E2=82=AC 75 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 109 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 135 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 135 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 194 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 233 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 341 =E2=82=AC 100 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 120 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 180 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 180 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 259 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 311 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 432 =E2=82=AC 125 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 150 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 216 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 216 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 324 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 379 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 513 =E2=82=AC 150 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 180 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 259 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 259 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 360 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 432 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 575 =E2=82=AC 175 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 202 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 302 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 302 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 399 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 479 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 626 =E2=82=AC 200 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 230 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 337 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 337 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 433 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 520 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 680 =E2=82=AC 250 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 288 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 421 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 421 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 515 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 596 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 807 =E2=82=AC 300 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 337 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 480 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 480 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 567 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 680 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 920 =E2=82=AC 350 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 393 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 532 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 523 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 628 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 754 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 020 =E2=82=AC 400 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 449 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 568 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 558 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 682 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 818 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 108 =E2=82=AC 450 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 497 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 596 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 596 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 729 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 874 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 221 =E2=82=AC 500 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 552 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 630 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 630 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 769 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 976 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 330 =E2=82=AC 600 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 629 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 718 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 718 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 877 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 172 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 564 =E2=82=AC 700 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 685 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 795 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 795 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 972 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 367 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 803 =E2=82=AC 800 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 744 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 864 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 864 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 085 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 562 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2 061 =E2=82=AC 900 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 795 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 923 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 915 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 220 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 757 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2 319 =E2=82=AC 1000 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 839 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 974 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 016 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 356 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 953 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2 576 =E2=82=AC =C2=A0 =C2=A0Tarifs panneaux akilux avec oeillet =C2=A0Panneaux=C2=A030x40 Panneau 40x60 =C2=A0 =C2=A0 =C2=A0=C2=A0Panneau 60x80 =C2=A0 =C2=A0 =C2=A0 =C2=A0 R=C2=B0 =C2=A0 =C2=A0R=C2=B0/ V=C2=B0 =C2=A0 =C2=A0 =C2=A0 =C2=A0R=C2=B0 =C2=A0 =C2=A0 =C2=A0 R=C2=B0 /V=C2=B0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0R=C2=B0 =C2=A0 =C2=A0 R=C2=B0/V=C2=B0=C2=A0 2 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 24 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 25 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 25 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 27 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 28 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 32 =E2=82=AC 4 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 28 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 31 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 31 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 35 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 37 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 44 =E2=82=AC 6 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 33 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 37 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 37 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 42 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 46 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 56 =E2=82=AC 8 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 37 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 42 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 42 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 50 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 54 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 68 =E2=82=AC 10 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 42 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 48 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 48 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 58 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 63 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 80 =E2=82=AC 15 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 53 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 63 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 63 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 77 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 85 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 110 =E2=82=AC 20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 64 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 77 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 77 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 96 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 107 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 136 =E2=82=AC 30 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 87 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 106 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 106 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 130 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 146 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 176 =E2=82=AC 35 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 98 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 120 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 120 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 148 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 167 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 205 =E2=82=AC 40 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 109 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 134 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 134 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 167 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 180 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 234 =E2=82=AC 50 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 132 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 159 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 159 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 185 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 212 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 283 =E2=82=AC 75 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 184 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 210 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 210 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 269 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 308 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 416 =E2=82=AC 100 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 220 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 280 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 280 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 359 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 411 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 532 =E2=82=AC 125 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 275 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 341 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 341 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 449 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 504 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 638 =E2=82=AC 150 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 330 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 409 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 409 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 510 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 582 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 725 =E2=82=AC 175 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 377 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 477 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 477 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 574 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 654 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 801 =E2=82=AC 200 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 430 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 537 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 537 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 633 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 720 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 880 =E2=82=AC 250 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 538 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 671 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 671 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 765 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 846 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 057 =E2=82=AC 300 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 637 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 780 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 780 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 867 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 980 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 220 =E2=82=AC 350 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 743 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 882 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 873 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 978 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 104 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 370 =E2=82=AC 400 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 849 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 968 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 958 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 082 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 218 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 508 =E2=82=AC 450 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 947 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 046 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 046 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 179 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 324 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 671 =E2=82=AC 500 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 052 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 130 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 130 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 269 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 476 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 830 =E2=82=AC 600 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 229 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 318 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 318 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 477 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 772 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2 164 =E2=82=AC 700 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 385 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 495 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 495 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 672 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2 067 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2 503 =E2=82=AC 800 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 544 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 664 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 664 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 885 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2 362 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2 861 =E2=82=AC 900 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 695 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 823 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 815 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2 120 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2 657 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3 219 =E2=82=AC 1000 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 839 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1 974 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2 016 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2 356 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2 953 =E2=82=AC =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3 576 =E2=82=AC =C2=A0 Ensemble, adaptons nos tarifs. =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bon =C3=A9t=C3=A9 _____________________________ D=C3=A9sinscription / Changer d'adresse e-mail: = http://ymlp225.net/ugbejhyqgsgueqjyqgehwmggmequss Powered par YourMailingListProvider From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 10:46:37 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4A8BD26C for ; Tue, 27 Aug 2013 10:46:37 +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]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F103E2DC0 for ; Tue, 27 Aug 2013 10:46:36 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1VEGn3-000FW4-Q3; Tue, 27 Aug 2013 13:46:25 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Rick Macklem Subject: Re: another? NFS deadlock on 9.2-PRERELEASE In-reply-to: <2024786487.13891803.1377551759314.JavaMail.root@uoguelph.ca> References: <2024786487.13891803.1377551759314.JavaMail.root@uoguelph.ca> Comments: In-reply-to Rick Macklem message dated "Mon, 26 Aug 2013 17:15:59 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Aug 2013 13:46:25 +0300 From: Daniel Braniss Message-ID: 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: Tue, 27 Aug 2013 10:46:37 -0000 > Daniel Braniss wrote: > > I upgraded our web server, and only after 3 hours it hung :-( > > (as a side note, I have 2 other web servers, also running 9.2 doing > > great :-) > > go figure. > > > > anyways, in > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/0 > > > > is the info after a forced panic. > > > Looks like the same hang to me. Several threads are sleeping on "pgrbwt" > and lots are waiting for an NFS vnode lock. > > It should be fixed in RC3 (or revert r250907). If it still hangs with > RC3 (or r250907 reverted), email again. > im following stable, hence it's till calling itself 9.2-PRERELEASE, but I did a sync this morning - local time, after rc3 was anounced. but after 3.45 minutes is hung, data in ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/1 I can't easely revert r250907, since i'm using mercuriall, but if someone can send me the pre r250907 files, i'll try. thanks, danny > rick > > > my guts say its running out of resources - mainly network related, > > but > > can't pinpoint it. > > > > any help will be most welcomed > > > > cheers, > > danny > > > > > > > > > > From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 10:58:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6F01E574 for ; Tue, 27 Aug 2013 10:58:09 +0000 (UTC) (envelope-from marko.cupac@mimar.rs) Received: from www.mimar.rs (www.mimar.rs [193.53.106.101]) by mx1.freebsd.org (Postfix) with ESMTP id 2DA632E92 for ; Tue, 27 Aug 2013 10:58:08 +0000 (UTC) Received: from kaa.mimar.rs (109-93-124-85.dynamic.isp.telekom.rs [109.93.124.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marko.cupac@mimar.rs) by www.mimar.rs (Postfix) with ESMTPSA id 28A52B9051 for ; Tue, 27 Aug 2013 12:58:02 +0200 (CEST) Date: Tue, 27 Aug 2013 12:58:00 +0200 From: Marko =?UTF-8?B?Q3VwYcSH?= To: freebsd-stable@freebsd.org Subject: virtualbox crashes r254557 Message-Id: <20130827125800.79c2f1949236949be6459c41@mimar.rs> Organization: Mimar X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 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: Tue, 27 Aug 2013 10:58:09 -0000 This happens a lot when using bridged ethernet. I have core dump. Should I post it here or send it to some email? Thank you in advance. -- Marko Cupać From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 12:09:37 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0AEB2822 for ; Tue, 27 Aug 2013 12:09:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id C61F322C8 for ; Tue, 27 Aug 2013 12:09:36 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMEAIOVHFKDaFve/2dsb2JhbABZDoMuUYMnvHyBPHSCJAEBAQMBAQEBICsgCwUWDgoCAg0ZAikBCSYGCAcEARwEh1oGDKV1klOBKYxyEA14NAeCaIExA5Umg3aQM4JhWyAyfAcXIg X-IronPort-AV: E=Sophos;i="4.89,968,1367985600"; d="scan'208";a="46852663" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 27 Aug 2013 08:09:22 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 603E8B3F91; Tue, 27 Aug 2013 08:09:22 -0400 (EDT) Date: Tue, 27 Aug 2013 08:09:22 -0400 (EDT) From: Rick Macklem To: Daniel Braniss Message-ID: <1740270726.14074212.1377605362382.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: another? NFS deadlock on 9.2-PRERELEASE MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) 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: Tue, 27 Aug 2013 12:09:37 -0000 Daniel Braniss wrote: > > Daniel Braniss wrote: > > > I upgraded our web server, and only after 3 hours it hung :-( > > > (as a side note, I have 2 other web servers, also running 9.2 > > > doing > > > great :-) > > > go figure. > > > > > > anyways, in > > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/0 > > > > > > is the info after a forced panic. > > > > > Looks like the same hang to me. Several threads are sleeping on > > "pgrbwt" > > and lots are waiting for an NFS vnode lock. > > > > It should be fixed in RC3 (or revert r250907). If it still hangs > > with > > RC3 (or r250907 reverted), email again. > > > im following stable, hence it's till calling itself 9.2-PRERELEASE, > but > I did a sync this morning - local time, after rc3 was anounced. > but after 3.45 minutes is hung, data in > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/1 > > I can't easely revert r250907, since i'm using mercuriall, but if > someone > can send me the pre r250907 files, i'll try. > r254947, which was committed to stable/9 a few hours ago is believed to fix the problem. Please update your stable/9 to post-r254947 and try it. rick > thanks, > danny > > > rick > > > > > my guts say its running out of resources - mainly network > > > related, > > > but > > > can't pinpoint it. > > > > > > any help will be most welcomed > > > > > > cheers, > > > danny > > > > > > > > > > > > > > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 12:39:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E624CC90 for ; Tue, 27 Aug 2013 12:39:02 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A693D2440 for ; Tue, 27 Aug 2013 12:39:02 +0000 (UTC) Received: by mail-vb0-f46.google.com with SMTP id p13so2899616vbe.5 for ; Tue, 27 Aug 2013 05:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=S3yZIW9gSM56lIh6ozdkMq3BSGqdW+jkGqrz5xrrcO0=; b=qyTMoAbESa3ibWbObtEQ75HWYuLA42V3jSazsdf/fYqO2ci4M8ATQmVRTJFqK6VBEd K2B507YWy93/Df3CJXvq4BlYyTkNWtRYBSOkh9FG0+K5DiA0jxniRbZW0+S0qFG+JZyD ZvG2y9uG5rW75HVPRnX0GjYpdKqZtWi/c1SnGQnx8k07mgUrr9mZ0sNqNqdxtRRaUm3O CeYxs70OaEyd/yL0Sq4Dkolc4+CcoSQQU6fzRJwzF0a0cky/IS9t1J3M/ay5V0roJoEG rIHu3XtoBNK9xBplVsFGt2s9DKwE1LwpfiXAlSzIOFQ7yXvIZdpBTFmbI7mFWbpNAchF cxAw== MIME-Version: 1.0 X-Received: by 10.221.51.206 with SMTP id vj14mr20108954vcb.17.1377607141621; Tue, 27 Aug 2013 05:39:01 -0700 (PDT) Received: by 10.58.249.1 with HTTP; Tue, 27 Aug 2013 05:39:01 -0700 (PDT) Date: Tue, 27 Aug 2013 14:39:01 +0200 Message-ID: Subject: make buildworld fails 9.2 PRERELEASE to RC3 From: Johan Hendriks To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 12:39:03 -0000 Hello all I am running the following version of FreeBSD uname -a FreeBSD beasty.testdomain.local 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254646: Thu Aug 22 09:46:05 CEST 2013 root@beasty.testdomain.local:/usr/obj/usr/src/sys/KRNL amd64 I have updated the source using the following command. svn co http://svn.freebsd.org/base/releng/9.2 /usr/src Checked out revision 254955. But when i do a buildworld it errors out. cc -O2 -pipe -march=core2 -DDES -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/bin/ed/undo.c cc -O2 -pipe -march=core2 -DDES -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o ed buf.o cbc.o glbl.o io.o main.o re.o sub.o undo.o -lcrypto gzip -cn /usr/src/bin/ed/ed.1 > ed.1.gz ===> bin/expr (all) cc -O2 -pipe -march=core2 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c expr.c cc1: warnings being treated as errors expr.c:812: warning: redundant redeclaration of 'yyparse' /usr/src/bin/expr/expr.y:77: warning: previous declaration of 'yyparse' was here *** [expr.o] Error code 1 Stop in /usr/src/bin/expr. *** [all] Error code 1 Stop in /usr/src/bin. *** [bin.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. I deleted /usr/obj/* I deleted /usr/src and did a new svn checkout. But the errors keeps coming. Is there anything i can do ! regards Johan From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 12:42:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3FBF5DEF; Tue, 27 Aug 2013 12:42:38 +0000 (UTC) (envelope-from Robert.Burmeister@utoledo.edu) Received: from smtpin2.utoledo.edu (smtpin2.utoledo.edu [131.183.2.214]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E505249D; Tue, 27 Aug 2013 12:42:37 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcAAHadHFKDtwN/l2dsb2JhbABahA2DJ74iFg4BAQEBAQgWBzyCThUbOyACBRYLAgsDAgECAUsBDAgBAYd9pgmJRokTgSmRKoExA54ZjnKCDg X-IronPort-AV: E=Sophos;i="4.89,968,1367985600"; d="scan'208";a="231272828" Received: from dlpint01.utoledo.edu ([131.183.3.127]) by smtpin2.utoledo.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Aug 2013 08:42:28 -0400 Received: from MsgApp11.utad.utoledo.edu (msgapp11.utad.utoledo.edu [131.183.3.7]) by dlpint01.utoledo.edu (RSA Interceptor); Tue, 27 Aug 2013 08:42:15 -0400 Received: from [192.168.1.65] (76.238.196.183) by Email.Utoledo.Edu (131.183.3.18) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 27 Aug 2013 08:42:15 -0400 Message-ID: <521C9E85.4060801@UToledo.edu> Date: Tue, 27 Aug 2013 08:41:41 -0400 From: Robert Burmeister User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: , , Subject: Suggest changing dirhash defaults for FreeBSD 9.2. X-Priority: 2 (High) Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [76.238.196.183] X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow 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, 27 Aug 2013 12:42:38 -0000 I have been experimenting with dirhash settings, and have scoured the internet for other peoples' experience with it. (I found the performance improvement in compiling has forestalled the need to add an SSD drive. ;-) I believe that increasing the following values by 10 would benefit most FreeBSD users without disadvantage. vfs.ufs.dirhash_maxmem: 2097152 to 20971520 vfs.ufs.dirhash_reclaimage: 5 to 50 or 60 FreeBSD administrators who have adjusted vfs.ufs.dirhash_maxmem for file server use have found 8 megs to be about minimum to satisfy vfs.ufs.dirhash_mem usage, while I have found compiling larger packages such as Firefox brings vfs.ufs.dirhash_mem up to about 13 megs. Setting vfs.ufs.dirhash_maxmem much larger than 20 megs results in vfs.ufs.dirhash_lowmemcount events scavenging excessive amounts of the directory cache, at 10% per event. I believe vfs.ufs.dirhash_reclaimage of about a minute is sufficient to reclaim memory without losing active directory cache, particularly when compiling; however my experience in operations leads me to believe this is also an optimal default for file servers. As the worst case scenario is that the directory cache will be over cleansed and the memory returned to the kernel, I would like to suggest that these defaults be raised by a factor of 10 for FreeBSD 9.2 or 10.0. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 13:04:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BB79A3FA for ; Tue, 27 Aug 2013 13:04:31 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 90E7425FF for ; Tue, 27 Aug 2013 13:04:31 +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 74567219A7 for ; Tue, 27 Aug 2013 09:04:28 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Tue, 27 Aug 2013 09:04:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=E9d+OWV7EuGKAw5M5SkDx3GFAU0=; b=sAp NPMIvVALSkpls7oZcKfRkYrMTkJYIdles4oH45GmxyWkagxpTtCVsMnFP1QO0Xp1 NBrJactvHuw60dDJw7nqqROp13LRUvsFqP80YgEddtMCv3cX9LvnKizMZGFtf8RQ +RHIF8q3xngOTGnTffA66Wb9XYDj+wxNtpB48LD4= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 4DDCBB02387; Tue, 27 Aug 2013 09:04:28 -0400 (EDT) Message-Id: <1377608668.7518.14651821.3D5D7DA1@webmail.messagingengine.com> X-Sasl-Enc: lrXg48ERUI7Tb1VI9JAxkNzsIqroU0n4QEN52PkSfOhR 1377608668 From: Mark Felder To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-be0d4992 In-Reply-To: <521C9E85.4060801@UToledo.edu> References: <521C9E85.4060801@UToledo.edu> Subject: Re: Suggest changing dirhash defaults for FreeBSD 9.2. Date: Tue, 27 Aug 2013 08:04:28 -0500 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, 27 Aug 2013 13:04:31 -0000 I've also toyed with dirhash on a few servers and received favorable results. I've no idea where the defaults currently come from, but I'm guessing probably around 1999 ;-) From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 13:40:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 123C9240 for ; Tue, 27 Aug 2013 13:40:03 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9F7EA2840 for ; Tue, 27 Aug 2013 13:40:02 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id b12so2007878wgh.18 for ; Tue, 27 Aug 2013 06:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K5K7XVkcwQP9uPobdTOvJAZbD6qZQkBRG4dLL2SEIfE=; b=OVj4Knt1+eeI4eUJvJefyC9HO8/r7SiQrHuklGO5/gOq6tUwtVnue2S4E8G+3V7Hyw Go44gC5cAajTV7bI7FcRlZKn+QXh7vR7mnor67DpBEeGysbcK+XkV6S2xOSkiWzs56yx O8jH++ALB5999zTiRF+HVXJvxVxG8KKp04z92/Aro2FAWCyXhH66GBybP2Roay3azktI 8O2tqdNDzqDZ2tTs9g2rYPQC7xUCMRssxP5ebI3pwwQsFtOzdm1cAdPmaA3E2BvBVG+p /LwaRdv9LrnMb0jfmyIwmn58O7+NyR0oHyv56NQ179LSfzDrBB6iOyzgm1HuKK0RvBXR tRuw== MIME-Version: 1.0 X-Received: by 10.180.207.84 with SMTP id lu20mr11587237wic.50.1377610800793; Tue, 27 Aug 2013 06:40:00 -0700 (PDT) Received: by 10.216.62.5 with HTTP; Tue, 27 Aug 2013 06:40:00 -0700 (PDT) In-Reply-To: <521C9E85.4060801@UToledo.edu> References: <521C9E85.4060801@UToledo.edu> Date: Tue, 27 Aug 2013 17:40:00 +0400 Message-ID: Subject: Re: Suggest changing dirhash defaults for FreeBSD 9.2. From: Sergey Kandaurov To: Robert Burmeister Content-Type: text/plain; charset=ISO-8859-1 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: Tue, 27 Aug 2013 13:40:03 -0000 On 27 August 2013 16:41, Robert Burmeister wrote: > > I have been experimenting with dirhash settings, and have scoured the internet for other peoples' experience with it. > (I found the performance improvement in compiling has forestalled the need to add an SSD drive. ;-) > > I believe that increasing the following values by 10 would benefit most FreeBSD users without disadvantage. > > vfs.ufs.dirhash_maxmem: 2097152 to 20971520 > > vfs.ufs.dirhash_reclaimage: 5 to 50 or 60 vfs.ufs.dirhash_maxmem is further autotuned based on available physical memory. See r214359 for details. -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 13:59:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1E4DB76C for ; Tue, 27 Aug 2013 13:59:22 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AA17B293E for ; Tue, 27 Aug 2013 13:59:21 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id q55so3946312wes.22 for ; Tue, 27 Aug 2013 06:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jSonMfBm/npj8tzVk/OQuptx/+Ctx1sWVbz+eL+Hf90=; b=b+R8e/FEUkP1eC6D5h1KEuzbubd4kX++BemcKq/rStyPbbyFw+I6FhN1DV60ZuE/rM xztbGOqavVRSFoCu6qw3+xadt1XtyRrlxanE39XSROregWx6Kbk42umU1QtL12+xTtXZ LqEXw8A7PHwIybJeD8sSTQtBCwDAsUHAB9/ngz6J1VFJJf+ugfROKu18ZbIuvJloLReg Bl0r5myyABh8JBz6FjUjsUnh83KLOJbJsLkoar8LAp7gbVjWz5y2DKS3lm246/8/njKx fkOauqA/GDfWeWJmOgRfKBmUHKEiamppdgb4PCz9OkNzW8vGXetvOx9yP2jNL+Tyriqb Cw6Q== MIME-Version: 1.0 X-Received: by 10.194.75.165 with SMTP id d5mr14195310wjw.18.1377611959979; Tue, 27 Aug 2013 06:59:19 -0700 (PDT) Received: by 10.194.157.69 with HTTP; Tue, 27 Aug 2013 06:59:19 -0700 (PDT) In-Reply-To: <20130827125800.79c2f1949236949be6459c41@mimar.rs> References: <20130827125800.79c2f1949236949be6459c41@mimar.rs> Date: Tue, 27 Aug 2013 15:59:19 +0200 Message-ID: Subject: Re: virtualbox crashes r254557 From: David Demelier To: =?UTF-8?B?TWFya28gQ3VwYcSH?= Content-Type: text/plain; charset=UTF-8 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: Tue, 27 Aug 2013 13:59:22 -0000 2013/8/27 Marko Cupa=C4=87 : > This happens a lot when using bridged ethernet. > > I have core dump. Should I post it here or send it to some email? > > Thank you in advance. > > -- > Marko Cupa=C4=87 > _______________________________________________ > 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" Yes you can paste the dump here --=20 Demelier David From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 14:00:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6EC52883 for ; Tue, 27 Aug 2013 14:00:23 +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]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 227E02983 for ; Tue, 27 Aug 2013 14:00:22 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1VEJoc-000IG5-1b; Tue, 27 Aug 2013 17:00:14 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Rick Macklem Subject: Re: another? NFS deadlock on 9.2-PRERELEASE In-reply-to: <1740270726.14074212.1377605362382.JavaMail.root@uoguelph.ca> References: <1740270726.14074212.1377605362382.JavaMail.root@uoguelph.ca> Comments: In-reply-to Rick Macklem message dated "Tue, 27 Aug 2013 08:09:22 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Aug 2013 17:00:14 +0300 From: Daniel Braniss Message-ID: 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: Tue, 27 Aug 2013 14:00:23 -0000 > Daniel Braniss wrote: > > > Daniel Braniss wrote: > > > > I upgraded our web server, and only after 3 hours it hung :-( > > > > (as a side note, I have 2 other web servers, also running 9.2 > > > > doing > > > > great :-) > > > > go figure. > > > > > > > > anyways, in > > > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/0 > > > > > > > > is the info after a forced panic. > > > > > > > Looks like the same hang to me. Several threads are sleeping on > > > "pgrbwt" > > > and lots are waiting for an NFS vnode lock. > > > > > > It should be fixed in RC3 (or revert r250907). If it still hangs > > > with > > > RC3 (or r250907 reverted), email again. > > > > > im following stable, hence it's till calling itself 9.2-PRERELEASE, > > but > > I did a sync this morning - local time, after rc3 was anounced. > > but after 3.45 minutes is hung, data in > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/1 > > > > I can't easely revert r250907, since i'm using mercuriall, but if > > someone > > can send me the pre r250907 files, i'll try. > > > r254947, which was committed to stable/9 a few hours ago is believed to > fix the problem. Please update your stable/9 to post-r254947 and try it. > the current kernel has that fix (sys/kern/uipc_syscalls.c) and if you check the core.txt/1 you will see no pgrbwt, only newnsf ... danny > rick > > > thanks, > > danny > > > > > rick > > > > > > > my guts say its running out of resources - mainly network > > > > related, > > > > but > > > > can't pinpoint it. > > > > > > > > any help will be most welcomed > > > > > > > > cheers, > > > > danny > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to > > "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 14:04:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A861FAF3 for ; Tue, 27 Aug 2013 14:04:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B702129DF for ; Tue, 27 Aug 2013 14:04:43 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r7RE4CdD072580; Tue, 27 Aug 2013 17:04:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r7RE4CdD072580 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r7RE4CNn072579; Tue, 27 Aug 2013 17:04:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 27 Aug 2013 17:04:12 +0300 From: Konstantin Belousov To: Daniel Braniss Subject: Re: another? NFS deadlock on 9.2-PRERELEASE Message-ID: <20130827140412.GQ4972@kib.kiev.ua> References: <1740270726.14074212.1377605362382.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wdMRLhhF94AmkTAJ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Rick Macklem , 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: Tue, 27 Aug 2013 14:04:44 -0000 --wdMRLhhF94AmkTAJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 27, 2013 at 05:00:14PM +0300, Daniel Braniss wrote: > > Daniel Braniss wrote: > > > > Daniel Braniss wrote: > > > > > I upgraded our web server, and only after 3 hours it hung :-( > > > > > (as a side note, I have 2 other web servers, also running 9.2 > > > > > doing > > > > > great :-) > > > > > go figure. > > > > >=20 > > > > > anyways, in > > > > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/0 > > > > >=20 > > > > > is the info after a forced panic. > > > > >=20 > > > > Looks like the same hang to me. Several threads are sleeping on > > > > "pgrbwt" > > > > and lots are waiting for an NFS vnode lock. > > > >=20 > > > > It should be fixed in RC3 (or revert r250907). If it still hangs > > > > with > > > > RC3 (or r250907 reverted), email again. > > > >=20 > > > im following stable, hence it's till calling itself 9.2-PRERELEASE, > > > but > > > I did a sync this morning - local time, after rc3 was anounced. > > > but after 3.45 minutes is hung, data in > > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/1 > > >=20 > > > I can't easely revert r250907, since i'm using mercuriall, but if > > > someone > > > can send me the pre r250907 files, i'll try. > > >=20 > > r254947, which was committed to stable/9 a few hours ago is believed to > > fix the problem. Please update your stable/9 to post-r254947 and try it. > >=20 > the current kernel has that fix (sys/kern/uipc_syscalls.c) > and if you check the core.txt/1 you will see no pgrbwt, only newnsf ... There is almost no useful information in the core.txt/1. Provide the known data for the deadlock. --wdMRLhhF94AmkTAJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSHLHbAAoJEJDCuSvBvK1BTpkP/0rAbMaQY5fluHUVrKgAL7j/ atmBubhUCw/fGCAgSVFhishEnHsLkt/is9z/hLvcf5SHGhpl8ItfRZtkAf5O7Lol ZU+GDsF3PvWr/6QOouoIP8xcVm2ofcXoUC+dncW3wXUfK9dWnv6PnPENK6H2kcqa 2NAq42nS+zC9/N7hEs1tKqNYkvI88+thsg5gd794InNfSaInPLsLo7YESvzSyPDy hqdZlcgNh/G45MW/Sz0PijH6dWIyLNxI5erFisrPYjH8WO0amph7tPL8UHeOhLyw 38ttERjUt/T/XeuIDUqEfG/iUBrxSMx8c2FKUpd1gvCzauWmhY+NTJ5mDDieWI3q MvSykmr5OG35Ry1W5qFtqT4klIB+SciB1T3xuhJA0ehAmeZNallaNzYBzN2kY7Xz 8jt1eGOLtetotAg0TZ8KReUrPKxuIxE1oGB+2F/VMlASGwJ001wlo3EinPMcAARg QwjOTDm+UeVCi2KBohOPRia3VliXeviA7PeyMFvrYoK4m7vsiR1dOcynnG0A8kud ZQFp8v+HJOty74t+4W3dVEQ3HSwUbrytdwUk3+1+e9gL8pBh77wkw4xE8kxyYgKY q7b+Dqc7eV/OdOVIkMHiOM8lid+fndLbsAX8mi68wQlLmH0P+8o3UhcQBVhfrsr9 fR+Yikq72uxcOk6wxg0U =OoJ0 -----END PGP SIGNATURE----- --wdMRLhhF94AmkTAJ-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 14:29:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1272C353; Tue, 27 Aug 2013 14:29:19 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from s1.omnilan.de (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6E7742B74; Tue, 27 Aug 2013 14:29:18 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by s1.omnilan.de (8.13.8/8.13.8) with ESMTP id r7RET5Hv049993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 16:29:06 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <521CB7AC.90605@omnilan.de> Date: Tue, 27 Aug 2013 16:29:00 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Bryan Venteicher Subject: Re: [CFT] VMware vmxnet3 ethernet driver References: <601099152.721.1375661537866.JavaMail.root@daemoninthecloset.org> <5214D37F.5000307@omnilan.de> <1117188271.19176.1377577117350.JavaMail.root@daemoninthecloset.org> In-Reply-To: <1117188271.19176.1377577117350.JavaMail.root@daemoninthecloset.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA68C03B9D347177ACD70FBCB" Cc: FreeBSD Stable , current@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, 27 Aug 2013 14:29:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA68C03B9D347177ACD70FBCB Content-Type: multipart/mixed; boundary="------------030705050708030202060003" This is a multi-part message in MIME format. --------------030705050708030202060003 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Bryan Venteicher's Nachricht vom 27.08.2013 06:18 (localt= ime): =2E.. >> It seems if_vmx doesn't support jumbo frames. If I set mtu 9000, I get= >> =C2=BBvmx0: cannot populate Rx queue 0=C2=AB, I have no problems using= jumbo >> frames with vmxnet3. >> > This could fail for two reasons - could not allocate an mbuf cluster, > or the call to bus_dmamap_load_mbuf_sg() failed. For the former, you > should check vmstat -z. For the later, the behavior of bus_dmamap_load_= mbuf_sg() > changed between 9.1 and 9.2, and I know it was broken for awhile. I don= 't > recall exactly when I fixed it (I think shortly after I made the origin= al > announcement). Could you retry with the files from HEAD @ [1]? Also, th= ere > are new sysctl oids (dev.vmx.X.mbuf_load_failed & dev.vmx.X.mgetcl_fail= ed) > for these errors. > > I just compiled the driver on 9.2-RC2 with the sources from HEAD and wa= s > able to change the MTU to 9000. > > [1]- http://svnweb.freebsd.org/base/head/sys/dev/vmware/vmxnet3/ Thanks a lot for your ongoing work! I can confirm that with recent if_vmx.c from head and compiled for 9.2-RC3, setting mtu to 9000 works as expected :-) >> I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ES= Xi >> 5.1U1 and FreeBSD-9.2-RC2 >> Two guests are connected to one MTU9000 "VMware Software Switch". >> > I've got a few performance things to still look at. What's the sysctl=20 > dev.vmx.X output for the if_vmx<->if_vmx tests? Just repeated if_vmx simple iperf bench, results vary slightly from standard 10sec run to run, but still noticable high Intr usage: if_vmx <-> if_vmx 1.32 GBits/sec, load: 10-45%Sys 40-48%Intr if_vmxJumbo <-> if_vmxJumbo 5.01 GBits/sec, load: 10-45%Sys 40-48%Intr Please find attached the different outputs of dev.vmx.X (the mtu9000 run = was only 3.47GBits/sec in that case, took the numbers anyway) wbr, -Harry --------------030705050708030202060003 Content-Type: text/plain; name="dev_vmx_iperfclient-i386_mtu1500.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dev_vmx_iperfclient-i386_mtu1500.txt" ZGV2LnZteC4wLiVkZXNjOiBWTXdhcmUgVk1YTkVUMyBFdGhlcm5ldCBBZGFwdGVyCmRldi52 bXguMC4lZHJpdmVyOiB2bXgKZGV2LnZteC4wLiVsb2NhdGlvbjogc2xvdD0wIGZ1bmN0aW9u PTAgaGFuZGxlPVxfU0JfLlBDSTAuUEU0MC5TMUYwCmRldi52bXguMC4lcG5waW5mbzogdmVu ZG9yPTB4MTVhZCBkZXZpY2U9MHgwN2IwIHN1YnZlbmRvcj0weDE1YWQgc3ViZGV2aWNlPTB4 MDdiMCBjbGFzcz0weDAyMDAwMApkZXYudm14LjAuJXBhcmVudDogcGNpMwpkZXYudm14LjAu bnR4cXVldWVzOiAxCmRldi52bXguMC5ucnhxdWV1ZXM6IDEKZGV2LnZteC4wLmNvbGxhcHNl ZDogMApkZXYudm14LjAubWdldGNsX2ZhaWxlZDogMApkZXYudm14LjAubWJ1Zl9sb2FkX2Zh aWxlZDogMApkZXYudm14LjAudHhxMC5yaW5nZnVsbDogMTMzNDc5CmRldi52bXguMC50eHEw Lm9mZmxvYWRfZmFpbGVkOiAwCmRldi52bXguMC50eHEwLmhzdGF0cy50c29fcGFja2V0czog NTY0OTg2CmRldi52bXguMC50eHEwLmhzdGF0cy50c29fYnl0ZXM6IDE2ODYxODQ1ODAKZGV2 LnZteC4wLnR4cTAuaHN0YXRzLnVjYXN0X3BhY2tldHM6IDU3MDYwNApkZXYudm14LjAudHhx MC5oc3RhdHMudW5pY2FzdF9ieXRlczogMTY5NDY3OTYwOApkZXYudm14LjAudHhxMC5oc3Rh dHMubWNhc3RfcGFja2V0czogMApkZXYudm14LjAudHhxMC5oc3RhdHMubWNhc3RfYnl0ZXM6 IDAKZGV2LnZteC4wLnR4cTAuaHN0YXRzLmVycm9yOiAwCmRldi52bXguMC50eHEwLmhzdGF0 cy5kaXNjYXJkOiAwCmRldi52bXguMC50eHEwLmRlYnVnLmNtZF9oZWFkOiAxMDYKZGV2LnZt eC4wLnR4cTAuZGVidWcuY21kX25leHQ6IDEwNgpkZXYudm14LjAudHhxMC5kZWJ1Zy5jbWRf bmRlc2M6IDUxMgpkZXYudm14LjAudHhxMC5kZWJ1Zy5jbWRfZ2VuOiAwCmRldi52bXguMC50 eHEwLmRlYnVnLmNvbXBfbmV4dDogMjM4CmRldi52bXguMC50eHEwLmRlYnVnLmNvbXBfbmRl c2M6IDUxMgpkZXYudm14LjAudHhxMC5kZWJ1Zy5jb21wX2dlbjogMQpkZXYudm14LjAucnhx MC5oc3RhdHMubHJvX3BhY2tldHM6IDAKZGV2LnZteC4wLnJ4cTAuaHN0YXRzLmxyb19ieXRl czogMApkZXYudm14LjAucnhxMC5oc3RhdHMudWNhc3RfcGFja2V0czogNTc5MTM3CmRldi52 bXguMC5yeHEwLmhzdGF0cy51bmljYXN0X2J5dGVzOiAzODQwOTMxMgpkZXYudm14LjAucnhx MC5oc3RhdHMubWNhc3RfcGFja2V0czogMApkZXYudm14LjAucnhxMC5oc3RhdHMubWNhc3Rf Ynl0ZXM6IDAKZGV2LnZteC4wLnJ4cTAuaHN0YXRzLmJjYXN0X3BhY2tldHM6IDI5CmRldi52 bXguMC5yeHEwLmhzdGF0cy5iY2FzdF9ieXRlczogMTc0MApkZXYudm14LjAucnhxMC5oc3Rh dHMubm9idWZmZXI6IDAKZGV2LnZteC4wLnJ4cTAuaHN0YXRzLmVycm9yOiAwCmRldi52bXgu MC5yeHEwLmRlYnVnLmNtZDBfZmlsbDogOTQKZGV2LnZteC4wLnJ4cTAuZGVidWcuY21kMF9u ZGVzYzogMjU2CmRldi52bXguMC5yeHEwLmRlYnVnLmNtZDBfZ2VuOiAwCmRldi52bXguMC5y eHEwLmRlYnVnLmNtZDFfZmlsbDogMApkZXYudm14LjAucnhxMC5kZWJ1Zy5jbWQxX25kZXNj OiAyNTYKZGV2LnZteC4wLnJ4cTAuZGVidWcuY21kMV9nZW46IDAKZGV2LnZteC4wLnJ4cTAu ZGVidWcuY29tcF9uZXh0OiA5NApkZXYudm14LjAucnhxMC5kZWJ1Zy5jb21wX25kZXNjOiA1 MTIKZGV2LnZteC4wLnJ4cTAuZGVidWcuY29tcF9nZW46IDAK --------------030705050708030202060003 Content-Type: text/plain; name="dev_vmx_iperfclient-i386_mtu9000.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dev_vmx_iperfclient-i386_mtu9000.txt" ZGV2LnZteC4wLiVkZXNjOiBWTXdhcmUgVk1YTkVUMyBFdGhlcm5ldCBBZGFwdGVyCmRldi52 bXguMC4lZHJpdmVyOiB2bXgKZGV2LnZteC4wLiVsb2NhdGlvbjogc2xvdD0wIGZ1bmN0aW9u PTAgaGFuZGxlPVxfU0JfLlBDSTAuUEU0MC5TMUYwCmRldi52bXguMC4lcG5waW5mbzogdmVu ZG9yPTB4MTVhZCBkZXZpY2U9MHgwN2IwIHN1YnZlbmRvcj0weDE1YWQgc3ViZGV2aWNlPTB4 MDdiMCBjbGFzcz0weDAyMDAwMApkZXYudm14LjAuJXBhcmVudDogcGNpMwpkZXYudm14LjAu bnR4cXVldWVzOiAxCmRldi52bXguMC5ucnhxdWV1ZXM6IDEKZGV2LnZteC4wLmNvbGxhcHNl ZDogMApkZXYudm14LjAubWdldGNsX2ZhaWxlZDogMApkZXYudm14LjAubWJ1Zl9sb2FkX2Zh aWxlZDogMApkZXYudm14LjAudHhxMC5yaW5nZnVsbDogNTg5NTAKZGV2LnZteC4wLnR4cTAu b2ZmbG9hZF9mYWlsZWQ6IDAKZGV2LnZteC4wLnR4cTAuaHN0YXRzLnRzb19wYWNrZXRzOiAy MzA1MDgKZGV2LnZteC4wLnR4cTAuaHN0YXRzLnRzb19ieXRlczogNDMxNDAyMDExMgpkZXYu dm14LjAudHhxMC5oc3RhdHMudWNhc3RfcGFja2V0czogMjM1MzgyCmRldi52bXguMC50eHEw LmhzdGF0cy51bmljYXN0X2J5dGVzOiA0MzU2OTQzNTUyCmRldi52bXguMC50eHEwLmhzdGF0 cy5tY2FzdF9wYWNrZXRzOiAwCmRldi52bXguMC50eHEwLmhzdGF0cy5tY2FzdF9ieXRlczog MApkZXYudm14LjAudHhxMC5oc3RhdHMuZXJyb3I6IDAKZGV2LnZteC4wLnR4cTAuaHN0YXRz LmRpc2NhcmQ6IDAKZGV2LnZteC4wLnR4cTAuZGVidWcuY21kX2hlYWQ6IDMzMwpkZXYudm14 LjAudHhxMC5kZWJ1Zy5jbWRfbmV4dDogMzMzCmRldi52bXguMC50eHEwLmRlYnVnLmNtZF9u ZGVzYzogNTEyCmRldi52bXguMC50eHEwLmRlYnVnLmNtZF9nZW46IDAKZGV2LnZteC4wLnR4 cTAuZGVidWcuY29tcF9uZXh0OiAzNzYKZGV2LnZteC4wLnR4cTAuZGVidWcuY29tcF9uZGVz YzogNTEyCmRldi52bXguMC50eHEwLmRlYnVnLmNvbXBfZ2VuOiAwCmRldi52bXguMC5yeHEw LmhzdGF0cy5scm9fcGFja2V0czogMApkZXYudm14LjAucnhxMC5oc3RhdHMubHJvX2J5dGVz OiAwCmRldi52bXguMC5yeHEwLmhzdGF0cy51Y2FzdF9wYWNrZXRzOiAyNTU5MTgKZGV2LnZt eC4wLnJ4cTAuaHN0YXRzLnVuaWNhc3RfYnl0ZXM6IDE3MDQzOTE4CmRldi52bXguMC5yeHEw LmhzdGF0cy5tY2FzdF9wYWNrZXRzOiAwCmRldi52bXguMC5yeHEwLmhzdGF0cy5tY2FzdF9i eXRlczogMApkZXYudm14LjAucnhxMC5oc3RhdHMuYmNhc3RfcGFja2V0czogMTUKZGV2LnZt eC4wLnJ4cTAuaHN0YXRzLmJjYXN0X2J5dGVzOiA5MDAKZGV2LnZteC4wLnJ4cTAuaHN0YXRz Lm5vYnVmZmVyOiAwCmRldi52bXguMC5yeHEwLmhzdGF0cy5lcnJvcjogMApkZXYudm14LjAu cnhxMC5kZWJ1Zy5jbWQwX2ZpbGw6IDEyMQpkZXYudm14LjAucnhxMC5kZWJ1Zy5jbWQwX25k ZXNjOiAyNTYKZGV2LnZteC4wLnJ4cTAuZGVidWcuY21kMF9nZW46IDEKZGV2LnZteC4wLnJ4 cTAuZGVidWcuY21kMV9maWxsOiAwCmRldi52bXguMC5yeHEwLmRlYnVnLmNtZDFfbmRlc2M6 IDI1NgpkZXYudm14LjAucnhxMC5kZWJ1Zy5jbWQxX2dlbjogMApkZXYudm14LjAucnhxMC5k ZWJ1Zy5jb21wX25leHQ6IDQ0NQpkZXYudm14LjAucnhxMC5kZWJ1Zy5jb21wX25kZXNjOiA1 MTIKZGV2LnZteC4wLnJ4cTAuZGVidWcuY29tcF9nZW46IDAK --------------030705050708030202060003 Content-Type: text/plain; name="dev_vmx_iperfserver-amd64_mtu1500.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dev_vmx_iperfserver-amd64_mtu1500.txt" ZGV2LnZteC4wLiVkZXNjOiBWTXdhcmUgVk1YTkVUMyBFdGhlcm5ldCBBZGFwdGVyCmRldi52 bXguMC4lZHJpdmVyOiB2bXgKZGV2LnZteC4wLiVsb2NhdGlvbjogc2xvdD0wIGZ1bmN0aW9u PTAgaGFuZGxlPVxfU0JfLlBDSTAuUEU0MS5TMUYwCmRldi52bXguMC4lcG5waW5mbzogdmVu ZG9yPTB4MTVhZCBkZXZpY2U9MHgwN2IwIHN1YnZlbmRvcj0weDE1YWQgc3ViZGV2aWNlPTB4 MDdiMCBjbGFzcz0weDAyMDAwMApkZXYudm14LjAuJXBhcmVudDogcGNpNApkZXYudm14LjAu bnR4cXVldWVzOiAxCmRldi52bXguMC5ucnhxdWV1ZXM6IDEKZGV2LnZteC4wLmNvbGxhcHNl ZDogMApkZXYudm14LjAubWdldGNsX2ZhaWxlZDogMApkZXYudm14LjAubWJ1Zl9sb2FkX2Zh aWxlZDogMApkZXYudm14LjAudHhxMC5yaW5nZnVsbDogMApkZXYudm14LjAudHhxMC5vZmZs b2FkX2ZhaWxlZDogMApkZXYudm14LjAudHhxMC5oc3RhdHMudHNvX3BhY2tldHM6IDAKZGV2 LnZteC4wLnR4cTAuaHN0YXRzLnRzb19ieXRlczogMApkZXYudm14LjAudHhxMC5oc3RhdHMu dWNhc3RfcGFja2V0czogNTc5MTM1CmRldi52bXguMC50eHEwLmhzdGF0cy51bmljYXN0X2J5 dGVzOiAzODQwOTE3NApkZXYudm14LjAudHhxMC5oc3RhdHMubWNhc3RfcGFja2V0czogMApk ZXYudm14LjAudHhxMC5oc3RhdHMubWNhc3RfYnl0ZXM6IDAKZGV2LnZteC4wLnR4cTAuaHN0 YXRzLmVycm9yOiAwCmRldi52bXguMC50eHEwLmhzdGF0cy5kaXNjYXJkOiAwCmRldi52bXgu MC50eHEwLmRlYnVnLmNtZF9oZWFkOiA2NApkZXYudm14LjAudHhxMC5kZWJ1Zy5jbWRfbmV4 dDogNjQKZGV2LnZteC4wLnR4cTAuZGVidWcuY21kX25kZXNjOiA1MTIKZGV2LnZteC4wLnR4 cTAuZGVidWcuY21kX2dlbjogMApkZXYudm14LjAudHhxMC5kZWJ1Zy5jb21wX25leHQ6IDY0 CmRldi52bXguMC50eHEwLmRlYnVnLmNvbXBfbmRlc2M6IDUxMgpkZXYudm14LjAudHhxMC5k ZWJ1Zy5jb21wX2dlbjogMApkZXYudm14LjAucnhxMC5oc3RhdHMubHJvX3BhY2tldHM6IDAK ZGV2LnZteC4wLnJ4cTAuaHN0YXRzLmxyb19ieXRlczogMApkZXYudm14LjAucnhxMC5oc3Rh dHMudWNhc3RfcGFja2V0czogMTE0NzE4NgpkZXYudm14LjAucnhxMC5oc3RhdHMudW5pY2Fz dF9ieXRlczogMTczMjA3MTE2MApkZXYudm14LjAucnhxMC5oc3RhdHMubWNhc3RfcGFja2V0 czogMApkZXYudm14LjAucnhxMC5oc3RhdHMubWNhc3RfYnl0ZXM6IDAKZGV2LnZteC4wLnJ4 cTAuaHN0YXRzLmJjYXN0X3BhY2tldHM6IDQ0CmRldi52bXguMC5yeHEwLmhzdGF0cy5iY2Fz dF9ieXRlczogMjY0MApkZXYudm14LjAucnhxMC5oc3RhdHMubm9idWZmZXI6IDMxMwpkZXYu dm14LjAucnhxMC5oc3RhdHMuZXJyb3I6IDAKZGV2LnZteC4wLnJ4cTAuZGVidWcuY21kMF9m aWxsOiA5NApkZXYudm14LjAucnhxMC5kZWJ1Zy5jbWQwX25kZXNjOiAyNTYKZGV2LnZteC4w LnJ4cTAuZGVidWcuY21kMF9nZW46IDEKZGV2LnZteC4wLnJ4cTAuZGVidWcuY21kMV9maWxs OiAwCmRldi52bXguMC5yeHEwLmRlYnVnLmNtZDFfbmRlc2M6IDI1NgpkZXYudm14LjAucnhx MC5kZWJ1Zy5jbWQxX2dlbjogMApkZXYudm14LjAucnhxMC5kZWJ1Zy5jb21wX25leHQ6IDM1 MApkZXYudm14LjAucnhxMC5kZWJ1Zy5jb21wX25kZXNjOiA1MTIKZGV2LnZteC4wLnJ4cTAu ZGVidWcuY29tcF9nZW46IDEK --------------030705050708030202060003 Content-Type: text/plain; name="dev_vmx_iperfserver-amd64_mtu9000.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dev_vmx_iperfserver-amd64_mtu9000.txt" ZGV2LnZteC4wLiVkZXNjOiBWTXdhcmUgVk1YTkVUMyBFdGhlcm5ldCBBZGFwdGVyCmRldi52 bXguMC4lZHJpdmVyOiB2bXgKZGV2LnZteC4wLiVsb2NhdGlvbjogc2xvdD0wIGZ1bmN0aW9u PTAgaGFuZGxlPVxfU0JfLlBDSTAuUEU0MS5TMUYwCmRldi52bXguMC4lcG5waW5mbzogdmVu ZG9yPTB4MTVhZCBkZXZpY2U9MHgwN2IwIHN1YnZlbmRvcj0weDE1YWQgc3ViZGV2aWNlPTB4 MDdiMCBjbGFzcz0weDAyMDAwMApkZXYudm14LjAuJXBhcmVudDogcGNpNApkZXYudm14LjAu bnR4cXVldWVzOiAxCmRldi52bXguMC5ucnhxdWV1ZXM6IDEKZGV2LnZteC4wLmNvbGxhcHNl ZDogMApkZXYudm14LjAubWdldGNsX2ZhaWxlZDogMApkZXYudm14LjAubWJ1Zl9sb2FkX2Zh aWxlZDogMApkZXYudm14LjAudHhxMC5yaW5nZnVsbDogMApkZXYudm14LjAudHhxMC5vZmZs b2FkX2ZhaWxlZDogMApkZXYudm14LjAudHhxMC5oc3RhdHMudHNvX3BhY2tldHM6IDAKZGV2 LnZteC4wLnR4cTAuaHN0YXRzLnRzb19ieXRlczogMApkZXYudm14LjAudHhxMC5oc3RhdHMu dWNhc3RfcGFja2V0czogMjU1OTE2CmRldi52bXguMC50eHEwLmhzdGF0cy51bmljYXN0X2J5 dGVzOiAxNzA0Mzc4MApkZXYudm14LjAudHhxMC5oc3RhdHMubWNhc3RfcGFja2V0czogMApk ZXYudm14LjAudHhxMC5oc3RhdHMubWNhc3RfYnl0ZXM6IDAKZGV2LnZteC4wLnR4cTAuaHN0 YXRzLmVycm9yOiAwCmRldi52bXguMC50eHEwLmhzdGF0cy5kaXNjYXJkOiAwCmRldi52bXgu MC50eHEwLmRlYnVnLmNtZF9oZWFkOiA0MjkKZGV2LnZteC4wLnR4cTAuZGVidWcuY21kX25l eHQ6IDQyOQpkZXYudm14LjAudHhxMC5kZWJ1Zy5jbWRfbmRlc2M6IDUxMgpkZXYudm14LjAu dHhxMC5kZWJ1Zy5jbWRfZ2VuOiAwCmRldi52bXguMC50eHEwLmRlYnVnLmNvbXBfbmV4dDog NDI5CmRldi52bXguMC50eHEwLmRlYnVnLmNvbXBfbmRlc2M6IDUxMgpkZXYudm14LjAudHhx MC5kZWJ1Zy5jb21wX2dlbjogMApkZXYudm14LjAucnhxMC5oc3RhdHMubHJvX3BhY2tldHM6 IDAKZGV2LnZteC4wLnJ4cTAuaHN0YXRzLmxyb19ieXRlczogMApkZXYudm14LjAucnhxMC5o c3RhdHMudWNhc3RfcGFja2V0czogNTAxMTg2CmRldi52bXguMC5yeHEwLmhzdGF0cy51bmlj YXN0X2J5dGVzOiA0MzcwMjQzODE2CmRldi52bXguMC5yeHEwLmhzdGF0cy5tY2FzdF9wYWNr ZXRzOiAwCmRldi52bXguMC5yeHEwLmhzdGF0cy5tY2FzdF9ieXRlczogMApkZXYudm14LjAu cnhxMC5oc3RhdHMuYmNhc3RfcGFja2V0czogOApkZXYudm14LjAucnhxMC5oc3RhdHMuYmNh c3RfYnl0ZXM6IDQ4MApkZXYudm14LjAucnhxMC5oc3RhdHMubm9idWZmZXI6IDI4NwpkZXYu dm14LjAucnhxMC5oc3RhdHMuZXJyb3I6IDAKZGV2LnZteC4wLnJ4cTAuZGVidWcuY21kMF9m aWxsOiAxNDcKZGV2LnZteC4wLnJ4cTAuZGVidWcuY21kMF9uZGVzYzogMjU2CmRldi52bXgu MC5yeHEwLmRlYnVnLmNtZDBfZ2VuOiAxCmRldi52bXguMC5yeHEwLmRlYnVnLmNtZDFfZmls bDogMjM0CmRldi52bXguMC5yeHEwLmRlYnVnLmNtZDFfbmRlc2M6IDI1NgpkZXYudm14LjAu cnhxMC5kZWJ1Zy5jbWQxX2dlbjogMQpkZXYudm14LjAucnhxMC5kZWJ1Zy5jb21wX25leHQ6 IDgwCmRldi52bXguMC5yeHEwLmRlYnVnLmNvbXBfbmRlc2M6IDUxMgpkZXYudm14LjAucnhx MC5kZWJ1Zy5jb21wX2dlbjogMAo= --------------030705050708030202060003-- --------------enigA68C03B9D347177ACD70FBCB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlIct7EACgkQLDqVQ9VXb8gmZwCfb+hB8luHCI5PK3Q1LGJacJ9B I0MAoL4Bj214AxpZ45K/+6nV5qtGQDKH =QsK5 -----END PGP SIGNATURE----- --------------enigA68C03B9D347177ACD70FBCB-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 14:53:07 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 594A4DAB; Tue, 27 Aug 2013 14:53:07 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (torment.daemoninthecloset.org [94.242.209.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 198E32D1C; Tue, 27 Aug 2013 14:53:06 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id B474D42C2632; Tue, 27 Aug 2013 16:58:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Virus-Scanned: amavisd-new at daemoninthecloset.org Date: Tue, 27 Aug 2013 09:52:52 -0500 (CDT) From: Bryan Venteicher To: Harald Schmalzbauer Message-ID: <1428315986.19291.1377615172231.JavaMail.root@daemoninthecloset.org> In-Reply-To: <521CB7AC.90605@omnilan.de> References: <601099152.721.1375661537866.JavaMail.root@daemoninthecloset.org> <5214D37F.5000307@omnilan.de> <1117188271.19176.1377577117350.JavaMail.root@daemoninthecloset.org> <521CB7AC.90605@omnilan.de> Subject: Re: [CFT] VMware vmxnet3 ethernet driver MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [192.168.10.20] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - GC20 ([unknown])/8.0.2_GA_5569) Thread-Topic: VMware vmxnet3 ethernet driver Thread-Index: m3nkTpbhAoxSRywSkYqJdsIgyubJ+g== Cc: FreeBSD Stable , current@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, 27 Aug 2013 14:53:07 -0000 ----- Original Message ----- > Bez=C3=BCglich Bryan Venteicher's Nachricht vom 27.08.2013 06:18 (localti= me): >=20 > ... >=20 > >> It seems if_vmx doesn't support jumbo frames. If I set mtu 9000, I get > >> =C2=BBvmx0: cannot populate Rx queue 0=C2=AB, I have no problems using= jumbo > >> frames with vmxnet3. > >> > > This could fail for two reasons - could not allocate an mbuf cluster, > > or the call to bus_dmamap_load_mbuf_sg() failed. For the former, you > > should check vmstat -z. For the later, the behavior of > > bus_dmamap_load_mbuf_sg() > > changed between 9.1 and 9.2, and I know it was broken for awhile. I don= 't > > recall exactly when I fixed it (I think shortly after I made the origin= al > > announcement). Could you retry with the files from HEAD @ [1]? Also, th= ere > > are new sysctl oids (dev.vmx.X.mbuf_load_failed & dev.vmx.X.mgetcl_fail= ed) > > for these errors. > > > > I just compiled the driver on 9.2-RC2 with the sources from HEAD and wa= s > > able to change the MTU to 9000. > > > > [1]- http://svnweb.freebsd.org/base/head/sys/dev/vmware/vmxnet3/ >=20 > Thanks a lot for your ongoing work! > I can confirm that with recent if_vmx.c from head and compiled for > 9.2-RC3, setting mtu to 9000 works as expected :-) >=20 >=20 > >> I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ES= Xi > >> 5.1U1 and FreeBSD-9.2-RC2 > >> Two guests are connected to one MTU9000 "VMware Software Switch". > >> > > I've got a few performance things to still look at. What's the sysctl > > dev.vmx.X output for the if_vmx<->if_vmx tests? >=20 > Just repeated if_vmx simple iperf bench, results vary slightly from > standard 10sec run to run, but still noticable high Intr usage: > The intr usage is higher than the other drivers you compared against because if_vmx does the off-level processing in ithreads where as the others do it in a taskqueue. BTW: if_vmx can to LRO as well. I don't think the emulated e1000 can, but I bet the e1000e does. > if_vmx <-> if_vmx > 1.32 GBits/sec, load: 10-45%Sys 40-48%Intr >=20 > if_vmxJumbo <-> if_vmxJumbo > 5.01 GBits/sec, load: 10-45%Sys 40-48%Intr >=20 > Please find attached the different outputs of dev.vmx.X (the mtu9000 run = was > only 3.47GBits/sec in that case, took the numbers anyway) >=20 > wbr, >=20 > -Harry >=20 >=20 From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 15:31:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AC8DDE0C for ; Tue, 27 Aug 2013 15:31:20 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 755222F34 for ; Tue, 27 Aug 2013 15:31:20 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id dn14so4812650obc.40 for ; Tue, 27 Aug 2013 08:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=PK2Pf2vreM1/L8GXYnZalP5DByGmqWEnL0LWZSdAVqI=; b=XezGTJxekGzQaOBix48og0xbIX+oJlPdMQsDpZ/pxeHFMcsYJQFS2trWt8eVo71URI 8Jp7dLkTqotTRoiGg2oLc4kGLtC4EIuN0/VNoI/MAmuwq5+cUgUwRbJkwHjovZHSOqBT l4Ype3BUhvWTDNiiQWt5Pz1FsODK/26K+0WM3tqpBsKMuf2MSsKNRn2+gK1DE+QXarzh E9Z57/awRyC/QmJ/WH3Ic15yOIFrcFlpKjUw8H32y5LJg2d1WN+gbZSt7NlpleV2TKQh zWyLPtMoetzIhFB/VIpe09wqhipGUgMTru0E0P4h4OS+ap8gljOCswracJVE5gt8Sdsd NvdA== X-Received: by 10.182.199.38 with SMTP id jh6mr2280960obc.33.1377617479725; Tue, 27 Aug 2013 08:31:19 -0700 (PDT) MIME-Version: 1.0 Sender: alexvpetrov@gmail.com Received: by 10.182.154.101 with HTTP; Tue, 27 Aug 2013 08:30:59 -0700 (PDT) In-Reply-To: References: From: "Alex V. Petrov" Date: Tue, 27 Aug 2013 23:30:59 +0800 X-Google-Sender-Auth: 579i1I07veSbCHebsNjQmLgeZr0 Message-ID: Subject: Re: make buildworld fails 9.2 PRERELEASE to RC3 To: Johan Hendriks Content-Type: text/plain; charset=ISO-8859-1 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: Tue, 27 Aug 2013 15:31:20 -0000 before 'make buildworld' need: cd /usr/src/usr.bin/yacc && make obj && make depend && make && make install 2013/8/27 Johan Hendriks > Hello all > > I am running the following version of FreeBSD > > uname -a > FreeBSD beasty.testdomain.local 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 > r254646: Thu Aug 22 09:46:05 CEST 2013 > root@beasty.testdomain.local:/usr/obj/usr/src/sys/KRNL > amd64 > > I have updated the source using the following command. > > svn co http://svn.freebsd.org/base/releng/9.2 /usr/src > Checked out revision 254955. > > But when i do a buildworld it errors out. > > > cc -O2 -pipe -march=core2 -DDES -std=gnu99 -fstack-protector > -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter > -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -c /usr/src/bin/ed/undo.c > cc -O2 -pipe -march=core2 -DDES -std=gnu99 -fstack-protector > -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter > -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -o ed buf.o cbc.o glbl.o io.o > main.o re.o sub.o undo.o -lcrypto > gzip -cn /usr/src/bin/ed/ed.1 > ed.1.gz > ===> bin/expr (all) > cc -O2 -pipe -march=core2 -std=gnu99 -fstack-protector -Wsystem-headers > -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -c expr.c > cc1: warnings being treated as errors > expr.c:812: warning: redundant redeclaration of 'yyparse' > /usr/src/bin/expr/expr.y:77: warning: previous declaration of 'yyparse' was > here > *** [expr.o] Error code 1 > > Stop in /usr/src/bin/expr. > *** [all] Error code 1 > > Stop in /usr/src/bin. > *** [bin.all__D] Error code 1 > > Stop in /usr/src. > *** [everything] Error code 1 > > Stop in /usr/src. > *** [buildworld] Error code 1 > > Stop in /usr/src. > > I deleted /usr/obj/* > I deleted /usr/src and did a new svn checkout. > > But the errors keeps coming. > > Is there anything i can do ! > > > regards > Johan > _______________________________________________ > 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 Aug 27 15:32:06 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AC54BF1B for ; Tue, 27 Aug 2013 15:32:06 +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]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5D9BF2F4E for ; Tue, 27 Aug 2013 15:32:06 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1VELFR-000J7V-Hv; Tue, 27 Aug 2013 18:32:01 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Konstantin Belousov Subject: Re: another? NFS deadlock on 9.2-PRERELEASE In-reply-to: <20130827140412.GQ4972@kib.kiev.ua> References: <1740270726.14074212.1377605362382.JavaMail.root@uoguelph.ca> <20130827140412.GQ4972@kib.kiev.ua> Comments: In-reply-to Konstantin Belousov message dated "Tue, 27 Aug 2013 17:04:12 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Aug 2013 18:32:01 +0300 From: Daniel Braniss Message-ID: Cc: Rick Macklem , 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: Tue, 27 Aug 2013 15:32:06 -0000 > > --wdMRLhhF94AmkTAJ > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Tue, Aug 27, 2013 at 05:00:14PM +0300, Daniel Braniss wrote: > > > Daniel Braniss wrote: > > > > > Daniel Braniss wrote: > > > > > > I upgraded our web server, and only after 3 hours it hung :-( > > > > > > (as a side note, I have 2 other web servers, also running 9.2 > > > > > > doing > > > > > > great :-) > > > > > > go figure. > > > > > >=20 > > > > > > anyways, in > > > > > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/0 > > > > > >=20 > > > > > > is the info after a forced panic. > > > > > >=20 > > > > > Looks like the same hang to me. Several threads are sleeping on > > > > > "pgrbwt" > > > > > and lots are waiting for an NFS vnode lock. > > > > >=20 > > > > > It should be fixed in RC3 (or revert r250907). If it still hangs > > > > > with > > > > > RC3 (or r250907 reverted), email again. > > > > >=20 > > > > im following stable, hence it's till calling itself 9.2-PRERELEASE, > > > > but > > > > I did a sync this morning - local time, after rc3 was anounced. > > > > but after 3.45 minutes is hung, data in > > > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/1 > > > >=20 > > > > I can't easely revert r250907, since i'm using mercuriall, but if > > > > someone > > > > can send me the pre r250907 files, i'll try. > > > >=20 > > > r254947, which was committed to stable/9 a few hours ago is believed to > > > fix the problem. Please update your stable/9 to post-r254947 and try it. > > >=20 > > the current kernel has that fix (sys/kern/uipc_syscalls.c) > > and if you check the core.txt/1 you will see no pgrbwt, only newnsf ... > > There is almost no useful information in the core.txt/1. > Provide the known data for the deadlock. maybe the word deadlock is too strong, the host is diskless (one of many) and so when NFS stops working/respondig, it hangs. I will now make it dataless - the / will be from local disk, see if that makes it easier to debug. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 14:41:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 595C5A41 for ; Tue, 27 Aug 2013 14:41:32 +0000 (UTC) (envelope-from marko.cupac@mimar.rs) Received: from www.mimar.rs (www.mimar.rs [193.53.106.101]) by mx1.freebsd.org (Postfix) with ESMTP id 930252C6A for ; Tue, 27 Aug 2013 14:41:30 +0000 (UTC) Received: from kaa.mimar.rs (109-93-124-85.dynamic.isp.telekom.rs [109.93.124.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marko.cupac@mimar.rs) by www.mimar.rs (Postfix) with ESMTPSA id 6C8AEB9051; Tue, 27 Aug 2013 16:41:26 +0200 (CEST) Date: Tue, 27 Aug 2013 16:41:25 +0200 From: Marko =?UTF-8?B?Q3VwYcSH?= To: David Demelier Subject: Re: virtualbox crashes r254557 Message-Id: <20130827164125.e5cac3824c79c8fffb2fd319@mimar.rs> In-Reply-To: References: <20130827125800.79c2f1949236949be6459c41@mimar.rs> Organization: Mimar X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd9.2) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 27 Aug 2013 15:46:58 +0000 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, 27 Aug 2013 14:41:32 -0000 On Tue, 27 Aug 2013 15:59:19 +0200 David Demelier wrote: > Yes you can paste the dump here kaa.mimar.rs dumped core - see /var/crash/vmcore.1 Tue Aug 27 12:34:13 CEST 2013 FreeBSD kaa.mimar.rs 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254557: Sun Aug 25 22:44:52 CEST 2013 pacija@kaa.mimar.rs:/usr/obj/usr/src/sys/KAAGEN amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xffffff8127951580 frame pointer = 0x28:0xffffff81279515b0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1929 (VirtualBox) trap number = 12 panic: page fault cpuid = 2 KDB: stack backtrace: #0 0xffffffff80948356 at kdb_backtrace+0x66 #1 0xffffffff8090deae at panic+0x1ce #2 0xffffffff80cf2c00 at trap_fatal+0x290 #3 0xffffffff80cf2f61 at trap_pfault+0x211 #4 0xffffffff80cf3514 at trap+0x344 #5 0xffffffff80cdc843 at calltrap+0x8 #6 0xffffffff8285cd5e at vboxNetFltPortOsXmit+0xee #7 0xffffffff8285dcb4 at vboxNetFltPortXmit+0x64 #8 0xffffffff828c83f8 at fuse_germ_vnops+0x55cf8 #9 0xffffffff828ca182 at fuse_germ_vnops+0x57a82 #10 0xffffffff828caf12 at fuse_germ_vnops+0x58812 #11 0xffffffff82889647 at fuse_germ_vnops+0x16f47 #12 0xffffffff828898a8 at fuse_germ_vnops+0x171a8 #13 0xffffffff825963b2 at supdrvIOCtl+0x1d12 #14 0xffffffff8259bef0 at VBoxDrvFreeBSDIOCtl+0x1d0 #15 0xffffffff807f4cbb at devfs_ioctl_f+0x7b #16 0xffffffff8095ae16 at kern_ioctl+0x106 #17 0xffffffff8095b05d at sys_ioctl+0xfd Uptime: 3h19m29s Dumping 734 out of 3984 MB:..3%..11%..22%..31%..42%..51%..61%..72%..81%..92% Reading symbols from /boot/kernel/acpi_video.ko...Reading symbols from /boot/kernel/acpi_video.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_video.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/tmpfs.ko Reading symbols from /boot/kernel/ng_ubt.ko...Reading symbols from /boot/kernel/ng_ubt.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ubt.ko Reading symbols from /boot/kernel/ng_hci.ko...Reading symbols from /boot/kernel/ng_hci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_hci.ko Reading symbols from /boot/kernel/ng_bluetooth.ko...Reading symbols from /boot/kernel/ng_bluetooth.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_bluetooth.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_l2cap.ko...Reading symbols from /boot/kernel/ng_l2cap.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_l2cap.ko Reading symbols from /boot/kernel/ng_btsocket.ko...Reading symbols from /boot/kernel/ng_btsocket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_btsocket.ko Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_socket.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko #0 doadump (textdump=) at pcpu.h:234 234 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:234 #1 0xffffffff8090d986 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0xffffffff8090de87 in panic (fmt=0x1
) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0xffffffff80cf2c00 in trap_fatal (frame=0xc, eva=) at /usr/src/sys/amd64/amd64/trap.c:879 #4 0xffffffff80cf2f61 in trap_pfault (frame=0xffffff81279514d0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:795 #5 0xffffffff80cf3514 in trap (frame=0xffffff81279514d0) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0xffffffff80cdc843 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0x0000000000000000 in ?? () (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -52 0 0 0 - DLs ?? 0:17.42 [kernel] 0 1 0 0 20 0 6276 0 wait DLs ?? 0:00.02 [init] 0 2 0 0 -16 0 0 0 waiting_ DL ?? 0:00.00 [sctp_iterator] 0 3 0 0 -16 0 0 0 ccb_scan DL ?? 0:00.00 [xpt_thrd] 0 4 0 0 -16 0 0 0 psleep DL ?? 0:00.01 [pagedaemon] 0 5 0 0 -16 0 0 0 psleep DL ?? 0:00.00 [vmdaemon] 0 6 0 0 155 0 0 0 pgzero DL ?? 0:00.00 [pagezero] 0 7 0 0 -16 0 0 0 psleep DL ?? 0:00.05 [bufdaemon] 0 8 0 0 16 0 0 0 syncer DL ?? 0:00.51 [syncer] 0 9 0 0 -16 0 0 0 vlruwt DL ?? 0:00.06 [vnlru] 0 10 0 0 -16 0 0 0 audit_wo DL ?? 0:00.00 [audit] 0 11 0 0 155 0 0 0 - RL ?? 1370:34.28 [idle] 0 12 0 0 -84 0 0 0 - WL ?? 5:06.20 [intr] 0 13 0 0 -8 0 0 0 - DL ?? 0:02.20 [geom] 0 14 0 0 -16 0 0 0 - DL ?? 0:00.75 [yarrow] 0 15 0 0 -68 0 0 0 - DL ?? 0:16.18 [usb] 0 16 0 0 -16 0 0 0 tzpoll DL ?? 0:00.24 [acpi_thermal] 0 17 0 0 -16 0 0 0 cooling DL ?? 0:00.01 [acpi_cooling0] 0 18 0 0 -20 0 0 0 VBoxIS DL ?? 0:04.37 [TIMER] 0 19 0 0 -16 0 0 0 sdflush DL ?? 0:00.13 [softdepflush] 0 167 1 0 52 0 9952 0 pause Ds ?? 0:00.00 [adjkerntz] 0 811 0 0 -16 0 0 0 sleep DL ?? 0:00.00 [ng_queue] 0 914 1 0 52 0 10376 0 select Ds ?? 0:00.01 [devd] 0 1138 1 0 20 0 12084 0 select Ds ?? 0:00.03 [syslogd] 0 1223 1 0 20 0 22264 0 select Ds ?? 0:00.41 [ntpd] 0 1226 1 0 20 0 12088 0 select Ds ?? 0:02.24 [powerd] 0 1245 1 0 52 0 12044 0 select Ds ?? 0:00.00 [in.tftpd] 939 1252 1 0 20 0 9952 0 select Ds ?? 0:00.00 [noip2] 556 1259 1 0 20 0 14348 0 select Ds ?? 0:01.13 [dbus-daemon] 0 1280 1 0 20 0 112620 0 n D ?? 0:00.04 [console-kit-daemon] 0 1282 1 0 20 0 66932 0 kqread D ?? 0:00.05 [polkitd] 0 1306 1 0 52 0 46880 0 select Ds ?? 0:00.00 [sshd] 0 1309 1 0 20 0 20340 0 select Ds ?? 0:00.14 [sendmail] 25 1312 1 0 20 0 20340 0 pause Ds ?? 0:00.00 [sendmail] 0 1317 1 0 20 0 14180 0 nanslp Ds ?? 0:00.03 [cron] 0 1367 1 0 52 0 12088 0 ttyin Ds+ ?? 0:00.00 [getty] 0 1368 1 0 52 0 45336 0 wait Ds ?? 0:00.01 [login] 0 1369 1 0 52 0 12088 0 ttyin Ds+ ?? 0:00.00 [getty] 0 1370 1 0 52 0 12088 0 ttyin Ds+ ?? 0:00.00 [getty] 0 1371 1 0 52 0 12088 0 ttyin Ds+ ?? 0:00.00 [getty] 0 1372 1 0 52 0 12088 0 ttyin Ds+ ?? 0:00.00 [getty] 0 1373 1 0 52 0 12088 0 ttyin Ds+ ?? 0:00.00 [getty] 0 1374 1 0 52 0 12088 0 ttyin Ds+ ?? 0:00.00 [getty] 1001 1379 1368 0 49 0 17568 0 pause D ?? 0:00.01 [tcsh] 560 1380 1 0 20 0 61616 0 select Ds ?? 0:02.10 [hald] 0 1381 1380 0 20 0 39624 0 select D ?? 0:00.03 [hald-runner] 1001 1383 1379 0 22 0 23712 0 wait D+ ?? 0:00.00 [xinit] 0 1385 1383 0 21 0 3310316 0 - R ?? 5:31.37 [Xorg] 0 1389 1381 0 21 0 29480 0 s D ?? 0:00.02 [hald-addon-mouse-s] 0 1421 1381 0 20 0 20924 0 e D ?? 0:03.38 [hald-addon-storage] 1001 1427 1383 0 52 0 14540 0 wait D ?? 0:00.00 [sh] 1001 1434 1427 0 52 0 43620 0 fffffe00064ca4a8 D ?? 0:00.00 [ck-launch-session] 1001 1450 1434 0 31 0 165468 0 select D ?? 0:00.72 [xfce4-session] 1001 1453 1 0 30 0 27968 0 select D ?? 0:00.00 [dbus-launch] 1001 1454 1 0 20 0 14348 0 select Ds ?? 0:00.10 [dbus-daemon] 1001 1456 1 0 20 0 41604 0 select D ?? 0:00.04 [xfconfd] 1001 1459 1 0 20 0 24020 0 select Ds ?? 0:00.23 [gpg-agent] 1001 1460 1450 0 20 0 158840 0 select D ?? 0:44.18 [xfwm4] 1001 1462 1450 0 20 0 388056 0 kqread D ?? 0:02.90 [xfce4-panel] 1001 1463 1 0 32 0 176672 0 kqread Ds ?? 0:00.37 [xfsettingsd] 1001 1465 1450 0 20 0 435116 0 uwait D ?? 0:01.75 [nautilus] 1001 1469 1 0 20 0 335436 0 e Ds ?? 0:03.05 [xfce4-power-manage] 1001 1473 1 0 20 0 48356 0 select D ?? 0:00.02 [gvfsd] 0 1475 1 0 20 0 56356 0 select D ?? 0:02.87 [upowerd] 1001 1479 1 0 20 0 62796 0 o D ?? 0:00.29 [gvfs-hal-volume-mo] 1001 1482 1 0 20 0 54880 0 m D ?? 0:00.03 [gvfs-gphoto2-volum] 1001 1484 1462 0 20 0 215696 0 select D ?? 0:00.63 [wrapper] 1001 1485 1462 0 20 0 155020 0 select D ?? 0:00.71 [wrapper] 1001 1486 1462 0 20 0 134588 0 p D ?? 0:00.15 [xfce4-orageclock-p] 1001 1492 1 0 20 0 48444 0 select D ?? 0:00.06 [gconfd-2] 1001 1498 1462 0 20 0 351652 0 select D ?? 0:00.12 [wrapper] 1001 1501 1 0 20 0 119384 0 uwait D ?? 0:05.04 [gvfsd-trash] 1001 1507 1 0 20 0 41612 0 select D ?? 0:00.01 [gvfsd-metadata] 1001 1549 1 0 20 0 680892 0 uwait D ?? 0:26.45 [chrome] 1001 1552 1549 0 20 0 955604 0 uwait D ?? 0:04.20 [chrome] 1001 1590 1 0 20 0 438088 0 select D ?? 0:09.64 [sylpheed] 1001 1602 1549 0 20 0 375856 0 kqread D ?? 0:05.27 [chrome] 1001 1606 1 0 29 0 344804 0 select D ?? 0:01.12 [gnome-terminal] 0 1607 1606 0 20 0 12104 0 sbwait D ?? 0:00.01 [gnome-pty-helper] 1001 1608 1606 0 20 0 21664 0 ttyin Ds+ ?? 0:00.05 [tcsh] 1001 1662 1606 0 21 0 17568 0 ttyin Ds+ ?? 0:00.03 [tcsh] 1001 1665 1 0 24 0 648192 0 select D ?? 0:13.65 [remmina] 1001 1669 1549 0 20 0 916940 0 uwait D ?? 0:02.79 [chrome] 1001 1672 1 0 20 0 73640 0 m D ?? 0:00.15 [gnome-keyring-daem] 1001 1695 1549 0 20 0 915896 0 uwait D ?? 0:01.17 [chrome] 1001 1823 1549 0 20 0 938144 0 uwait D ?? 0:08.88 [chrome] 1001 1826 1606 0 20 0 17568 0 pause Ds ?? 0:00.03 [tcsh] 1001 1829 1826 0 20 0 38392 0 select D+ ?? 0:00.03 [ssh] 1001 1834 1549 0 20 0 936156 0 uwait D ?? 0:01.88 [chrome] 1001 1866 1606 0 20 0 17568 0 ttyin Ds+ ?? 0:00.03 [tcsh] 1001 1929 1 0 20 0 1637020 1132928 select D ?? 32:18.30 [VirtualBox] 1001 1931 1 0 20 0 51956 0 select D ?? 0:00.59 [VBoxXPCOMIPCD] 1001 1933 1 0 20 0 122792 0 uwait D ?? 0:01.63 [VBoxSVC] 1001 2007 1549 0 21 0 907772 0 uwait D ?? 0:00.58 [chrome] 1001 2047 1606 0 20 0 17568 0 ttyin Ds+ ?? 0:00.03 [tcsh] 0 2150 1 0 25 0 18388 0 select Ds ?? 0:00.00 [wpa_supplicant] 0 2267 1 0 52 0 12084 0 select Ds ?? 0:00.00 [dhclient] 65 2286 1 0 52 0 12084 0 select Ds ?? 0:00.00 [dhclient] ------------------------------------------------------------------------ vmstat -s 3262176476 cpu context switches 25008590 device interrupts 7722829 software interrupts 2696984 traps 3800825037 system calls 20 kernel threads created 1669 fork() calls 598 vfork() calls 0 rfork() calls 774 swap pager pageins 819 swap pager pages paged in 25131 swap pager pageouts 25131 swap pager pages paged out 17231 vnode pager pageins 70833 vnode pager pages paged in 1873 vnode pager pageouts 10954 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 15192 pages reactivated 111956 copy-on-write faults 234 copy-on-write optimized faults 540843 zero fill pages zeroed 584 zero fill pages prezeroed 848 intransit blocking page faults 1182500 total VM faults taken 0 pages affected by kernel thread creation 893108 pages affected by fork() 360964 pages affected by vfork() 0 pages affected by rfork() 0 pages cached 723827 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 149673 pages active 229849 pages inactive 22746 pages in VM cache 434345 pages wired down 144558 pages free 4096 bytes per page 1630870 total name lookups cache hits (84% pos + 9% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) CAM SIM 4 1K - 4 256 acpidev 44 3K - 44 64 USBdev 58 17K - 5470 64,128,512 isadev 8 1K - 8 128 USB 56 114K - 64 16,32,128,256,512,1024,2048,4096 cdev 8 2K - 8 256 entropy 1024 64K - 1024 64 sigio 2 1K - 2 64 filedesc 146 101K - 2431 16,32,512,1024,2048,4096 kdtrace 492 105K - 10044 64,256 kenv 84 12K - 95 16,32,64,128 kqueue 70 78K - 753 256,512,2048 proc-args 72 6K - 3657 16,32,64,128,256 hhook 2 1K - 2 256 kbdmux 6 18K - 6 16,512,1024,2048 ithread 107 18K - 107 32,128,256 LED 12 1K - 12 16,128 KTRACE 100 13K - 100 128 linker 376 467K - 473 16,32,64,128,256,512,1024,2048,4096 lockf 63 8K - 9286 64,128 loginclass 1 1K - 65 64 ip6ndp 8 1K - 15 64,128 temp 60 40K - 55450 16,32,64,128,256,512,1024,2048,4096 devbuf 18059 36099K - 18505 16,32,64,128,256,512,1024,2048,4096 module 494 62K - 494 128 pci_link 16 2K - 16 64,128 mtx_pool 2 16K - 2 hdaa 21 37K - 21 256,512,1024,2048 hdac 2 2K - 2 512,1024 osd 2 1K - 2 16,64 hdacc 5 1K - 5 32 pmchooks 1 1K - 1 128 acpi_perf 8 2K - 8 256 subproc 296 491K - 2486 512,4096 proc 2 32K - 2 session 36 5K - 108 128 pgrp 41 6K - 139 128 cred 72 12K - 204818 64,256 uidinfo 8 5K - 115 128,4096 plimit 14 4K - 985 256 sysctltmp 0 0K - 1234 16,32,64,128,4096 sysctloid 6638 331K - 6818 16,32,64,128 sysctl 0 0K - 7455 16,32,64 tidhash 1 32K - 1 callout 7 3584K - 7 umtx 1110 139K - 1110 128 p1003.1b 1 1K - 1 16 SWAP 2 549K - 2 64 bus-sc 134 446K - 6168 16,32,64,128,256,512,1024,2048,4096 bus 1415 124K - 9565 16,32,64,128,256,512,1024,2048 devstat 4 9K - 4 32,4096 eventhandler 91 8K - 91 64,128 feeder 28 3K - 148 32,128 kobj 344 1376K - 517 4096 CAM periph 6 2K - 19 16,32,64,128,256 Per-cpu 1 1K - 1 32 DEVFS1 126 63K - 142 512 DEVFS3 143 36K - 167 256 rman 259 30K - 681 16,32,128 sbuf 0 0K - 1384 16,32,64,128,256,512,1024,2048,4096 sglist 62 167K - 182 32,128,512,1024,2048 DEVFS_RULE 61 29K - 61 64,512 DEVFS 23 1K - 24 16,128 stack 0 0K - 2 256 taskqueue 23 2K - 23 16,32,128 Unitno 18 1K - 15338 32,64 iov 0 0K - 2769495 16,32,64,128,256,512 select 183 23K - 183 128 ioctlops 2 1K - 533207990 16,32,64,128,256,512,1024,2048 msg 4 30K - 4 2048,4096 sem 4 106K - 4 2048,4096 shm 19 56K - 79 2048 tty 22 22K - 26 1024,2048 pts 5 2K - 7 256 mbuf_tag 0 0K - 9857 32,64 shmfd 1 8K - 1 DEVFSP 30 2K - 5478 64 pcb 27 157K - 1584 16,32,64,128,1024,2048,4096 soname 121 14K - 7307 16,32,64,128 vfscache 1 2048K - 1 cl_savebuf 0 0K - 264 64 vfs_hash 1 1024K - 1 msdosfs_node 182 46K - 15561 256 vnodes 2 1K - 2 256 msdosfs_fileno 112 7K - 112 64 mount 83 4K - 175 16,32,64,128,256 vnodemarker 0 0K - 2326 512 BPF 17 1035K - 35 16,128,512,4096 ether_multi 19 1K - 84 16,32,64 ifaddr 337 26K - 398 32,64,128,256,512,4096 ifnet 8 15K - 11 128,2048 msdosfs_fat 1 1988K - 1 clone 6 24K - 6 4096 arpcom 2 1K - 3 16 lltable 17 8K - 31 256,512 msdosfs_mount 1 1K - 1 512 tun 0 0K - 2 256 routetbl 33 5K - 582 32,64,128,256,512 80211vap 1 4K - 2 4096 80211crypto 2 1K - 8 128,512 80211com 1 8K - 1 80211nodeie 3 1K - 83 32,128,256 80211node 2 17K - 8 1024 80211scan 3 7K - 8 512,2048,4096 igmp 7 2K - 10 256 in_multi 2 1K - 9 256 sctp_iter 0 0K - 14 256 sctp_ifn 2 1K - 9 128 sctp_ifa 4 1K - 11 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 14 16 hostcache 1 28K - 1 syncache 1 96K - 1 in6_multi 15 2K - 35 32,256 mld 7 1K - 10 128 NFS FHA 1 2K - 1 2048 rpc 2 1K - 2 256 audit_evclass 180 6K - 219 32 jblocks 2 1K - 2 128,256 savedino 0 0K - 258 256 sbdep 0 0K - 306 64 jsegdep 9 1K - 9115 64 jseg 4 1K - 833 128 jfreefrag 0 0K - 772 128 jnewblk 0 0K - 5722 128 jremref 0 0K - 1273 128 jaddref 0 0K - 1348 128 freedep 0 0K - 38 64 freework 4 1K - 1823 64,128 newdirblk 0 0K - 3 64 dirrem 3 1K - 1271 128 mkdir 0 0K - 6 128 diradd 3 1K - 1342 128 freefile 0 0K - 729 64 freeblks 3 1K - 780 256 freefrag 0 0K - 772 128 indirdep 0 0K - 44 128 newblk 4 129K - 5723 256 bmsafemap 3 9K - 1284 256 inodedep 14 1031K - 2204 512 pagedep 3 129K - 521 256 ufs_dirhash 114 40K - 262 16,32,64,128,256,512 ufs_quota 1 1024K - 1 ufs_mount 3 13K - 3 512,4096 vm_pgdata 2 513K - 2 128 UMAHash 5 13K - 13 512,1024,2048,4096 pfs_nodes 21 6K - 21 256 pfs_vncache 62 4K - 105 64 GEOM 69 20K - 590 16,32,64,128,256,512,1024,2048 memdesc 1 4K - 2 4096 atkbddev 2 1K - 2 64 mixer 6 24K - 6 4096 acpiintr 1 1K - 1 64 acpica 8242 839K - 632017 16,32,64,128,256,512,1024,2048,4096 acpitask 1 8K - 1 CAM dev queue 4 1K - 4 128 raid_data 0 0K - 78 32,128,256 md_nvidia_data 0 0K - 12 512 apmdev 1 1K - 1 128 madt_table 0 0K - 1 4096 acpisem 74 10K - 74 128 md_sii_data 0 0K - 12 512 CAM path 8 1K - 28 32 athdev 3 70K - 3 2048 io_apic 1 2K - 1 2048 CAM CCB 35 70K - 23871 2048 scsi_cd 0 0K - 14 16 MCA 18 3K - 18 64,128 msi 12 2K - 12 128 nexusdev 3 1K - 3 16 ath_hal 3 15K - 3 128,2048 CAM DEV 6 12K - 9 2048 CAM XPT 25 2K - 67 16,32,64,128,256,1024 CAM queue 17 1K - 45 16,32,64,512 acpivideo 3 1K - 3 128 linux 16 1K - 16 64 nvidia 9835 30482K - 1508162 16,32,64,128,256,512,1024,2048,4096 iprtheap 2922 5185K - 30349 32,64,128,256,512,1024,2048,4096 tmpfs name 37 1K - 1084 16,32 tmpfs mount 1 1K - 1 128 netgraph_node 12 3K - 24 128,256 netgraph_hook 10 2K - 14 128 netgraph_msg 2 1K - 44 64,128,256,1024 netgraph 2 1K - 3 64 netgraph_hci 1 1K - 1 256 netgraph_l2cap 1 1K - 1 128 netgraph_btsocks_hci_raw 1 8K - 23 128 netgraph_btsocks_l2cap_raw 1 1K - 1 32 netgraph_btsocks_l2cap 1 1K - 1 32 netgraph_sock 0 0K - 18 128 netgraph_path 0 0K - 11 16 fuse_messaging 0 0K - 1 512 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 94, 8, 94, 0, 0 UMA Zones: 1408, 0, 94, 0, 94, 0, 0 UMA Slabs: 568, 0, 3080, 7, 5674, 0, 0 UMA RCntSlabs: 568, 0, 1342, 2, 1502, 0, 0 UMA Hash: 256, 0, 0, 0, 5, 0, 0 16 Bucket: 152, 0, 182, 43, 216, 0, 0 32 Bucket: 280, 0, 239, 13, 276, 0, 0 64 Bucket: 536, 0, 226, 19, 265, 94, 0 128 Bucket: 1048, 0, 317, 1, 365,17093, 0 VM OBJECT: 232, 0, 9826, 686, 55622, 0, 0 MAP: 240, 0, 8, 24, 8, 0, 0 KMAP ENTRY: 128, 166460, 448, 799, 98055, 0, 0 MAP ENTRY: 128, 0, 9260, 1093, 141406, 0, 0 fakepg: 120, 0, 5005, 3830, 22980, 0, 0 mt_zone: 4112, 0, 350, 86, 350, 0, 0 16: 16, 0, 3199, 833, 2274098, 0, 0 32: 32, 0, 4354, 1605, 205514, 0, 0 64: 64, 0, 14683, 1893,533967837, 0, 0 128: 128, 0, 12393, 1208, 1765124, 0, 0 256: 256, 0, 2465, 1165, 159871, 0, 0 512: 512, 0, 1628, 507, 16978, 0, 0 1024: 1024, 0, 177, 283, 85022, 0, 0 2048: 2048, 0, 192, 288, 75021, 0, 0 4096: 4096, 0, 534, 190, 32753, 0, 0 Files: 80, 0, 1029, 681, 177052, 0, 0 rl_entry: 40, 0, 127, 629, 127, 0, 0 TURNSTILE: 136, 0, 556, 84, 556, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1192, 0, 97, 98, 2287, 0, 0 THREAD: 1160, 0, 393, 162, 7755, 0, 0 SLEEPQUEUE: 80, 0, 556, 198, 556, 0, 0 VMSPACE: 400, 0, 78, 147, 2269, 0, 0 cpuset: 72, 0, 82, 118, 82, 0, 0 audit_record: 960, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 1570260, 297, 1370, 651755, 0, 0 mbuf: 256, 1570260, 8, 1531, 2958570, 0, 0 mbuf_cluster: 2048, 51200, 1536, 106, 1673, 0, 0 mbuf_jumbo_page: 4096, 122676, 1, 520, 648819, 0, 0 mbuf_jumbo_9k: 9216, 109044, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 81784, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 ttyinq: 160, 0, 600, 168, 765, 0, 0 ttyoutq: 256, 0, 312, 108, 400, 0, 0 g_bio: 248, 0, 0, 1860, 347001, 0, 0 ata_request: 328, 0, 0, 0, 0, 0, 0 ata_composite: 336, 0, 0, 0, 0, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 nv_stack_t: 12288, 0, 7, 112, 23905, 0, 0 FPU_save_area: 512, 0, 0, 0, 0, 0, 0 VNODE: 504, 0, 3847, 257, 21044, 0, 0 VNODEPOLL: 112, 0, 139, 224, 140, 0, 0 NAMEI: 1024, 0, 0, 160, 444696, 0, 0 S VFS Cache: 108, 0, 3735, 291, 93948, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 109, 155, 259, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 132, 100, 662, 0, 0 NCLNODE: 568, 0, 0, 0, 0, 0, 0 pipe: 728, 0, 138, 82, 1748, 0, 0 Mountpoints: 824, 0, 5, 3, 5, 0, 0 ksiginfo: 112, 0, 183, 906, 347093, 0, 0 itimer: 344, 0, 2, 31, 2, 0, 0 KNOTE: 128, 0, 237, 430, 539783, 0, 0 socket: 680, 25002, 306, 150, 12544, 0, 0 ipq: 56, 1638, 0, 0, 0, 0, 0 udp_inpcb: 392, 25000, 11, 109, 11201, 0, 0 udpcb: 16, 25032, 11, 1165, 11201, 0, 0 tcp_inpcb: 392, 25000, 11, 189, 419, 0, 0 tcpcb: 976, 25000, 11, 181, 419, 0, 0 tcptw: 72, 5000, 0, 450, 125, 0, 0 syncache: 152, 15375, 0, 50, 1, 0, 0 hostcache: 136, 15372, 5, 275, 72, 0, 0 tcpreass: 40, 3276, 0, 924, 2043, 0, 0 sackhole: 32, 0, 0, 909, 262, 0, 0 sctp_ep: 1384, 25000, 0, 0, 0, 0, 0 sctp_asoc: 2288, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 504, 17, 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: 104, 400032, 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, 25000, 1, 69, 7, 0, 0 unpcb: 240, 25008, 280, 184, 826, 0, 0 rtentry: 200, 0, 13, 158, 41, 0, 0 selfd: 56, 0, 489, 1149,89039578, 0, 0 SWAPMETA: 288, 490711, 2136, 451, 3385, 0, 0 FFS inode: 168, 0, 3458, 194, 4191, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 3458, 307, 4187, 0, 0 TMPFS dirent: 40, 0, 36, 720, 1083, 0, 0 TMPFS node: 224, 0, 50, 358, 1083, 0, 0 NetGraph items: 72, 4118, 2, 230, 69, 0, 0 NetGraph data items: 72, 522, 0, 290, 37139, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq1: atkbd0 24776 229 irq9: acpi0 16370 151 irq12: psm0 343969 3184 irq16: vgapci0+ 1954164 18094 irq17: hdac0 ath0 242438 2244 irq23: ehci1 24048 222 irq256: hpet0:t0 2211264 20474 irq257: hpet0:t1 3500239 32409 irq258: hpet0:t2 3216537 29782 irq259: hpet0:t3 3020989 27972 irq260: hpet0:t4 1516602 14042 irq261: hpet0:t5 2573615 23829 irq262: hpet0:t6 4724461 43745 irq263: hpet0:t7 1224876 11341 irq264: hdac1 298302 2762 irq267: ahci0 115940 1073 Total 25008590 231561 ------------------------------------------------------------------------ pstat -T 1029/25000 files 80M/4095M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/ada0s2b 8388328 165512 8222816 2% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics ada0 cd0 pass0 cpu KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 24.90 898 21.85 0.00 0 0.00 0.00 0 0.00 10 0 4 0 86 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME m 65536 1346981710 --rw-rw-rw- noip noip noip noip 1 2016 1252 1252 9:13:00 no-entry 9:13:00 m 131073 0 --rw------- pacija pacija pacija pacija 2 393216 1460 1385 9:13:12 11:29:38 9:13:12 m 65538 0 --rw------- pacija pacija pacija pacija 2 393216 1460 1385 9:13:15 11:29:38 9:13:15 m 65539 0 --rw------- pacija pacija pacija pacija 2 393216 1484 1385 9:13:17 11:29:38 9:13:17 m 65540 0 --rw------- pacija pacija pacija pacija 2 393216 1469 1385 9:13:20 11:29:38 9:13:20 m 131077 0 --rw------- pacija pacija pacija pacija 2 393216 1465 1385 9:13:23 11:29:38 9:13:23 m 65542 0 --rw------- pacija pacija pacija pacija 2 393216 1465 1385 9:13:26 11:29:38 9:13:26 m 65543 0 --rw------- pacija pacija pacija pacija 2 393216 1462 1385 9:43:10 11:29:38 9:43:10 m 65544 0 --rw------- pacija pacija pacija pacija 2 393216 1549 1385 9:43:14 12:08:21 9:43:14 m 65545 0 --rw------- pacija pacija pacija pacija 2 393216 1549 1385 9:43:18 12:08:21 9:43:18 m 524298 0 --rw------- pacija pacija pacija pacija 2 393216 1606 1385 9:59:34 12:31:13 9:59:34 m 196619 0 --rw------- pacija pacija pacija pacija 2 393216 1590 1385 9:58:51 11:29:38 9:58:51 m 196620 0 --rw------- pacija pacija pacija pacija 2 393216 1590 1385 9:58:51 11:29:38 9:58:51 m 196621 0 --rw------- pacija pacija pacija pacija 2 393216 1606 1385 10:12:30 12:31:13 10:12:30 m 65550 0 --rw------- pacija pacija pacija pacija 2 393216 1665 1385 10:12:38 11:29:38 10:12:38 m 65551 0 --rw------- pacija pacija pacija pacija 2 393216 1665 1385 10:12:38 11:29:38 10:12:38 m 1376272 0 --rwarwarwa pacija pacija pacija pacija 2 4196352 1929 1385 11:29:39 11:29:39 11:29:39 m 327698 0 --rwarwarwa pacija pacija pacija pacija 2 219064 1929 1385 11:29:44 no-entry 11:29:44 Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME s 65536 1442840576 --rw------- pacija pacija pacija pacija 1 11:29:38 11:29:37 ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) seminfo: semmni: 50 (# of semaphore identifiers) semmns: 340 (# of semaphores in system) semmnu: 150 (# of undo structures in system) semmsl: 340 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 50 (max # of undo entries per process) semusz: 632 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 0 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 0 0 0 0 0 0 0 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses Accs Hits Misses 0 0 0 0 0 0 0 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 ------------------------------------------------------------------------ netstat -s tcp: 37277 packets sent 21241 data packets (1008585 bytes) 369 data packets (67190 bytes) retransmitted 19 data packets unnecessarily retransmitted 13 resends initiated by MTU discovery 14923 ack-only packets (2170 delayed) 0 URG only packets 0 window probe packets 78 window update packets 714 control packets 39240 packets received 12948 acks (for 1007545 bytes) 2407 duplicate acks 0 acks for unsent data 25331 packets (25679909 bytes) received in-sequence 68 completely duplicate packets (35599 bytes) 4 old duplicate packets 1 packet with some dup. data (21 bytes duped) 2042 out-of-order packets (2659962 bytes) 0 packets (0 bytes) of data after window 0 window probes 16 window update packets 17 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 372 connection requests 1 connection accept 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 366 connections established (including accepts) 408 connections closed (including 21 drops) 139 connections updated cached RTT on close 141 connections updated cached RTT variance on close 10 connections updated cached ssthresh on close 7 embryonic connections dropped 12905 segments updated rtt (of 11829 attempts) 136 retransmit timeouts 2 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 1183 keepalive timeouts 1178 keepalive probes sent 5 connections dropped by keepalive 6863 correct ACK header predictions 21648 correct data packet header predictions 1 syncache entry added 0 retransmitted 0 dupsyn 0 dropped 1 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 1 cookie sent 0 cookies received 72 hostcache entries added 0 bucket overflow 171 SACK recovery episodes 210 segment rexmits in SACK recovery episodes 4483 byte rexmits in SACK recovery episodes 1104 SACK options (SACK blocks) received 2036 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 10372 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 38 dropped due to no socket 9695 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 639 delivered 660 datagrams output 0 times multicast source filter matched ip: 73617 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 73598 packets for this host 16 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 3 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 70223 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 3 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 38 calls to icmp_error 0 errors not generated in response to an icmp message Output histogram: destination unreachable: 38 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored Input histogram: destination unreachable: 14 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 2 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent arp: 9 ARP requests sent 276 ARP replies sent 612 ARP requests received 3 ARP replies received 628 ARP packets received 5 total packets dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ip6: 0 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 packets reassembled ok 0 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 2 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 1423 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 0 multicast packets which we don't join Mbuf statistics: 0 one mbuf 0 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not contiguous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 0 failures of source address selection Source addresses selection rule applied: icmp6: 0 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation Output histogram: neighbor solicitation: 2 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 0 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output ------------------------------------------------------------------------ netstat -m 305/2901/3206 mbufs in use (current/cache/total) 166/1476/1642/51200 mbuf clusters in use (current/cache/total/max) 297/1370 mbuf+clusters out of packet secondary zone in use (current/cache) 1/520/521/122676 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/109044 9k jumbo clusters in use (current/cache/total/max) 0/0/0/81784 16k jumbo clusters in use (current/cache/total/max) 412K/5757K/6169K 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 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ------------------------------------------------------------------------ netstat -id Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop usbus 0 0 0 0 0 0 0 0 ath0 2290 48:5d:60:5f:96:e6 167951 11018 0 62910 0 0 0 usbus 0 0 0 0 0 0 0 0 alc0 1500 48:5b:39:9b:e8:e0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 lo0 16384 26 0 0 26 0 0 0 lo0 16384 localhost ::1 0 - - 0 - - - lo0 16384 fe80::1%lo0 fe80::1 0 - - 0 - - - lo0 16384 your-net localhost 26 - - 26 - - - wlan0 1500 48:5d:60:5f:96:e6 6 0 0 4 0 0 0 wlan0 1500 192.168.1.0 kaa 0 - - 0 - - - ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.1 UGS 0 0 wlan0 127.0.0.1 link#6 UH 0 26 lo0 192.168.1.0/24 link#7 U 0 0 wlan0 192.168.1.10 link#7 UHS 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 ::1 link#6 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 fe80::/10 ::1 UGRS lo0 fe80::%lo0/64 link#6 U lo0 fe80::1%lo0 link#6 UHS lo0 ff01::%lo0/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%lo0/32 ::1 U lo0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) fffffe0020dccb70 tcp4 0 0 192.168.1.10.16258 157.249.32.164.80 CLOSE_WAIT fffffe00640387a0 tcp4 0 0 192.168.131.226.21 192.168.5.28.22 ESTABLISHED fffffe00aa1e7000 tcp4 0 0 192.168.1.10.59539 72.32.20.57.80 ESTABLISHED fffffe00aa27eb70 tcp4 0 450 192.168.131.226.10 10.20.4.42.3389 ESTABLISHED fffffe0006bb0000 tcp4 0 16 192.168.1.10.18937 193.53.106.39.1723 FIN_WAIT_1 fffffe0006bc1b70 tcp4 0 0 192.168.1.10.10768 193.53.106.101.143 ESTABLISHED fffffe00066517a0 tcp4 0 0 *.6000 *.* LISTEN fffffe0006651b70 tcp6 0 0 *.6000 *.* LISTEN fffffe0006cae7a0 tcp4 0 0 127.0.0.1.25 *.* LISTEN fffffe0006c1e7a0 tcp4 0 0 *.22 *.* LISTEN fffffe0006c1eb70 tcp6 0 0 *.22 *.* LISTEN fffffe00066cc620 udp4 0 0 192.168.1.10.123 *.* fffffe00066cbc40 udp4 0 0 *.* *.* fffffe00066f47a8 udp6 0 0 *.69 *.* fffffe00066f4930 udp4 0 0 *.69 *.* fffffe00066e2310 udp4 0 0 127.0.0.1.123 *.* fffffe00066e2498 udp6 0 0 fe80:6::1.123 *.* fffffe00066e27a8 udp6 0 0 ::1.123 *.* fffffe00066e2ab8 udp6 0 0 *.123 *.* fffffe00066e2c40 udp4 0 0 *.123 *.* fffffe00066ccab8 udp4 0 0 *.514 *.* fffffe00066ccc40 udp6 0 0 *.514 *.* Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr fffffe00069730f0 stream 0 0 0 fffffe0083bcab40 0 0 fffffe0083bcab40 stream 0 0 0 fffffe00069730f0 0 0 fffffe00834d32d0 stream 0 0 0 fffffe00835d05a0 0 0 fffffe00835d05a0 stream 0 0 0 fffffe00834d32d0 0 0 fffffe0083ea90f0 stream 0 0 0 fffffe0083e0cd20 0 0 /tmp/.X11-unix/X0 fffffe0083e0cd20 stream 0 0 0 fffffe0083ea90f0 0 0 fffffe0006924690 stream 0 0 0 fffffe0083e05d20 0 0 /tmp/.X11-unix/X0 fffffe0083e05d20 stream 0 0 0 fffffe0006924690 0 0 fffffe0083e05c30 stream 0 0 0 fffffe0083e04000 0 0 /tmp/.X11-unix/X0 fffffe0083e04000 stream 0 0 0 fffffe0083e05c30 0 0 fffffe0083e052d0 stream 0 0 0 fffffe0006924870 0 0 /tmp/.vbox-pacija-ipc/ipcd fffffe0006924870 stream 0 0 0 fffffe0083e052d0 0 0 fffffe00834d3d20 stream 0 0 0 fffffe0083ea8780 0 0 /tmp/.vbox-pacija-ipc/ipcd fffffe0083ea8780 stream 0 0 0 fffffe00834d3d20 0 0 fffffe0083e040f0 stream 0 0 fffffe00207101f8 0 0 0 /tmp/.vbox-pacija-ipc/ipcd fffffe00069234b0 stream 0 0 0 fffffe0083ad94b0 0 0 /tmp/.ICE-unix/1450 fffffe0083ad94b0 stream 0 0 0 fffffe00069234b0 0 0 fffffe0083e05000 stream 4244 0 0 fffffe0083f58960 0 0 /tmp/.X11-unix/X0 fffffe0083f58960 stream 0 0 0 fffffe0083e05000 0 0 fffffe0083ea81e0 stream 0 0 0 fffffe0083bcaa50 0 0 fffffe0083bcaa50 stream 0 0 0 fffffe0083ea81e0 0 0 fffffe0006924780 stream 0 0 0 fffffe0083e04c30 0 0 fffffe0083e04c30 stream 0 0 0 fffffe0006924780 0 0 fffffe0083ada4b0 stream 0 0 0 fffffe0083ada3c0 0 0 fffffe0083ada3c0 stream 0 0 0 fffffe0083ada4b0 0 0 fffffe00835d0e10 stream 0 0 0 fffffe0006a59780 0 0 fffffe0006a59780 stream 0 0 0 fffffe00835d0e10 0 0 fffffe0083e0c690 stream 0 0 0 fffffe0083e0cc30 0 0 fffffe0083e0cc30 stream 0 0 0 fffffe0083e0c690 0 0 fffffe0006948b40 stream 0 0 0 fffffe00835d0a50 0 0 fffffe00835d0a50 stream 0 0 0 fffffe0006948b40 0 0 fffffe0083f58c30 stream 0 0 0 fffffe0083ea8a50 0 0 /tmp/dbus-L2n5TYXqCj fffffe0083ea8a50 stream 0 0 0 fffffe0083f58c30 0 0 fffffe0083e044b0 stream 0 0 0 fffffe0083e045a0 0 0 /tmp/dbus-L2n5TYXqCj fffffe0083e045a0 stream 0 0 0 fffffe0083e044b0 0 0 fffffe0083e05e10 stream 0 0 fffffe0134d773f0 0 0 0 /tmp/keyring-BRttYV/control fffffe0006711960 stream 0 0 0 fffffe0083e053c0 0 0 /tmp/dbus-L2n5TYXqCj fffffe0083e053c0 stream 0 0 0 fffffe0006711960 0 0 fffffe0083ada1e0 stream 0 0 0 fffffe0083ada2d0 0 0 /tmp/dbus-L2n5TYXqCj fffffe0083ada2d0 stream 0 0 0 fffffe0083ada1e0 0 0 fffffe0083e0c000 stream 0 0 0 fffffe0083e0c0f0 0 0 fffffe0083e0c0f0 stream 0 0 0 fffffe0083e0c000 0 0 fffffe0083ada5a0 stream 0 0 0 fffffe0083ada690 0 0 fffffe0083ada690 stream 0 0 0 fffffe0083ada5a0 0 0 fffffe0006a592d0 stream 0 0 0 fffffe0006711870 0 0 /tmp/dbus-L2n5TYXqCj fffffe0006711870 stream 0 0 0 fffffe0006a592d0 0 0 fffffe0083f585a0 stream 0 0 0 fffffe0083f583c0 0 0 /tmp/dbus-L2n5TYXqCj fffffe0083f583c0 stream 0 0 0 fffffe0083f585a0 0 0 fffffe0083ea80f0 stream 0 0 0 fffffe00835d0780 0 0 /tmp/.X11-unix/X0 fffffe00835d0780 stream 0 0 0 fffffe0083ea80f0 0 0 fffffe0083ea8690 stream 0 0 0 fffffe0083ea82d0 0 0 fffffe0083ea82d0 stream 0 0 0 fffffe0083ea8690 0 0 fffffe0083e0c3c0 stream 0 0 0 fffffe0083e0c4b0 0 0 /tmp/dbus-L2n5TYXqCj fffffe0083e0c4b0 stream 0 0 0 fffffe0083e0c3c0 0 0 fffffe0083bca4b0 stream 0 0 0 fffffe0083bca5a0 0 0 /tmp/orbit-pacija/linc-646-0-eb581dcabd06 fffffe0083bca5a0 stream 0 0 0 fffffe0083bca4b0 0 0 fffffe0083e0d870 stream 0 0 fffffe0083eef000 0 0 0 /tmp/orbit-pacija/linc-646-0-eb581dcabd06 fffffe0083e0d960 stream 0 0 0 fffffe0083e0da50 0 0 /tmp/orbit-pacija/linc-5d4-0-7e5ceec686567 fffffe0083e0da50 stream 0 0 0 fffffe0083e0d960 0 0 fffffe00835d0870 stream 0 0 0 fffffe00835d0960 0 0 /tmp/dbus-L2n5TYXqCj fffffe00835d0960 stream 0 0 0 fffffe00835d0870 0 0 fffffe0083e0db40 stream 0 0 0 fffffe0083e0dc30 0 0 /tmp/.ICE-unix/1450 fffffe0083e0dc30 stream 0 0 0 fffffe0083e0db40 0 0 fffffe0083e0dd20 stream 0 0 0 fffffe0083e0de10 0 0 /tmp/.X11-unix/X0 fffffe0083e0de10 stream 0 0 0 fffffe0083e0dd20 0 0 fffffe0083e04960 stream 0 0 0 fffffe0083e04a50 0 0 fffffe0083e04a50 stream 0 0 0 fffffe0083e04960 0 0 fffffe0083ad9000 stream 0 0 0 fffffe0083ea9780 0 0 /tmp/.X11-unix/X0 fffffe0083ea9780 stream 0 0 0 fffffe0083ad9000 0 0 fffffe0083ea9870 stream 0 0 0 fffffe0083ea9960 0 0 /tmp/.X11-unix/X0 fffffe0083ea9960 stream 0 0 0 fffffe0083ea9870 0 0 fffffe00835d0c30 stream 0 0 0 fffffe00835d0d20 0 0 fffffe00835d0d20 stream 0 0 0 fffffe00835d0c30 0 0 fffffe0083ea9a50 stream 0 0 0 fffffe0083ea9b40 0 0 /tmp/dbus-L2n5TYXqCj fffffe0083ea9b40 stream 0 0 0 fffffe0083ea9a50 0 0 fffffe0083ea83c0 stream 0 0 0 fffffe0083ea84b0 0 0 /tmp/.X11-unix/X0 fffffe0083ea84b0 stream 0 0 0 fffffe0083ea83c0 0 0 fffffe0083ea85a0 stream 0 0 fffffe0083dd8bd0 0 0 0 /tmp/sylpheed-1001 fffffe000670a3c0 stream 0 0 0 fffffe0083f58d20 0 0 fffffe0083f58d20 stream 0 0 0 fffffe000670a3c0 0 0 fffffe0083ad91e0 stream 0 0 0 fffffe0083ad92d0 0 0 fffffe0083ad92d0 stream 0 0 0 fffffe0083ad91e0 0 0 fffffe0083ea8c30 stream 0 0 0 fffffe0083ea8d20 0 0 /tmp/dbus-L2n5TYXqCj fffffe0083ea8d20 stream 0 0 0 fffffe0083ea8c30 0 0 fffffe0083f58a50 stream 0 0 fffffe0083f68dc8 0 0 0 /tmp/.org.chromium.Chromium.jZlfDS/SingletonSocket fffffe0083ea8e10 stream 0 0 0 fffffe0083ea9000 0 0 /tmp/.X11-unix/X0 fffffe0083ea9000 stream 0 0 0 fffffe0083ea8e10 0 0 fffffe0083f59690 stream 0 0 0 fffffe0083bcac30 0 0 /tmp/dbus-L2n5TYXqCj fffffe0083bcac30 stream 0 0 0 fffffe0083f59690 0 0 fffffe0083e0d1e0 stream 0 0 0 fffffe0083e0d2d0 0 0 /tmp/dbus-L2n5TYXqCj fffffe0083e0d2d0 stream 0 0 0 fffffe0083e0d1e0 0 0 fffffe0006a5a5a0 stream 0 0 0 fffffe0006a5a690 0 0 /tmp/gvfs-pacija-EBfrsOzn/socket1 fffffe0006a5a690 stream 0 0 0 fffffe0006a5a5a0 0 0 fffffe0006a5a780 stream 0 0 0 fffffe0006a5a870 0 0 /tmp/gvfs-pacija-EBfrsOzn/socket2 fffffe0006a5a870 stream 0 0 0 fffffe0006a5a780 0 0 fffffe008364f000 stream 0 0 0 fffffe008364f0f0 0 0 /var/run/dbus/system_bus_socket fffffe008364f0f0 stream 0 0 0 fffffe008364f000 0 0 fffffe0006972690 stream 0 0 0 fffffe00069235a0 0 0 /tmp/dbus-L2n5TYXqCj fffffe00069235a0 stream 0 0 0 fffffe0006972690 0 0 fffffe0083e0d3c0 stream 0 0 0 fffffe0083e0d4b0 0 0 /tmp/dbus-L2n5TYXqCj fffffe0083e0d4b0 stream 0 0 0 fffffe0083e0d3c0 0 0 fffffe008364f1e0 stream 0 0 0 fffffe008364f2d0 0 0 /tmp/gvfs-pacija-FXWbqfzx/socket1 fffffe008364f2d0 stream 0 0 0 fffffe008364f1e0 0 0 fffffe008364f3c0 stream 0 0 0 fffffe008364f4b0 0 0 /tmp/gvfs-pacija-FXWbqfzx/socket2 fffffe008364f4b0 stream 0 0 0 fffffe008364f3c0 0 0 fffffe0083e0d5a0 stream 0 0 0 fffffe0083e0d690 0 0 /tmp/dbus-L2n5TYXqCj fffffe0083e0d690 stream 0 0 0 fffffe0083e0d5a0 0 0 fffffe0083e0d780 stream 0 0 0 fffffe000670ae10 0 0 fffffe000670ae10 stream 0 0 0 fffffe0083e0d780 0 0 fffffe000670ad20 stream 0 0 0 fffffe00069484b0 0 0 /tmp/dbus-L2n5TYXqCj fffffe00069484b0 stream 0 0 0 fffffe000670ad20 0 0 fffffe0083e05870 stream 0 0 0 fffffe0083e05960 0 0 /tmp/dbus-L2n5TYXqCj fffffe0083e05960 stream 0 0 0 fffffe0083e05870 0 0 fffffe0006a5ad20 stream 0 0 0 fffffe0006a5ae10 0 0 /tmp/dbus-L2n5TYXqCj fffffe0006a5ae10 stream 0 0 0 fffffe0006a5ad20 0 0 fffffe0083ad9780 stream 0 0 0 fffffe0083ad9870 0 0 /tmp/dbus-L2n5TYXqCj fffffe0083ad9870 stream 0 0 0 fffffe0083ad9780 0 0 fffffe0083ad9960 stream 0 0 0 fffffe0083ad9a50 0 0 fffffe0083ad9a50 stream 0 0 0 fffffe0083ad9960 0 0 fffffe0083ad9b40 stream 0 0 0 fffffe0083ad9c30 0 0 /tmp/dbus-L2n5TYXqCj fffffe0083ad9c30 stream 0 0 0 fffffe0083ad9b40 0 0 fffffe00834d3000 stream 0 0 0 fffffe00834d30f0 0 0 /tmp/dbus-L2n5TYXqCj fffffe00834d30f0 stream 0 0 0 fffffe00834d3000 0 0 fffffe0006972870 stream 0 0 0 fffffe0006973d20 0 0 /tmp/orbit-pacija/linc-5b9-0-4846a814db049 fffffe0006973d20 stream 0 0 0 fffffe0006972870 0 0 fffffe008364f780 stream 0 0 fffffe00835743f0 0 0 0 /tmp/orbit-pacija/linc-5b9-0-4846a814db049 fffffe0083ad9d20 stream 0 0 0 fffffe000670b000 0 0 /tmp/orbit-pacija/linc-5d4-0-7e5ceec686567 fffffe000670b000 stream 0 0 0 fffffe0083ad9d20 0 0 fffffe000670a5a0 stream 0 0 0 fffffe0006a594b0 0 0 /var/run/dbus/system_bus_socket fffffe0006a594b0 stream 0 0 0 fffffe000670a5a0 0 0 fffffe0006948870 stream 0 0 0 fffffe0006948780 0 0 /var/run/dbus/system_bus_socket fffffe0006948780 stream 0 0 0 fffffe0006948870 0 0 fffffe00069241e0 stream 0 0 0 fffffe0006973b40 0 0 /tmp/dbus-L2n5TYXqCj fffffe0006973b40 stream 0 0 0 fffffe00069241e0 0 0 fffffe0006a59b40 stream 0 0 0 fffffe0006948690 0 0 /tmp/.X11-unix/X0 fffffe0006948690 stream 0 0 0 fffffe0006a59b40 0 0 fffffe00069733c0 stream 0 0 0 fffffe00069732d0 0 0 /tmp/dbus-L2n5TYXqCj fffffe00069732d0 stream 0 0 0 fffffe00069733c0 0 0 fffffe00069731e0 stream 0 0 fffffe00835749d8 0 0 0 /tmp/orbit-pacija/linc-5d4-0-7e5ceec686567 fffffe008364f960 stream 0 0 0 fffffe008364fa50 0 0 /tmp/.ICE-unix/1450 fffffe008364fa50 stream 0 0 0 fffffe008364f960 0 0 fffffe008364fb40 stream 0 0 0 fffffe008364fc30 0 0 /tmp/.X11-unix/X0 fffffe008364fc30 stream 0 0 0 fffffe008364fb40 0 0 fffffe0083ada000 stream 0 0 0 fffffe0083ada0f0 0 0 /tmp/dbus-L2n5TYXqCj fffffe0083ada0f0 stream 0 0 0 fffffe0083ada000 0 0 fffffe00067113c0 stream 0 0 0 fffffe000670a4b0 0 0 fffffe000670a4b0 stream 0 0 0 fffffe00067113c0 0 0 fffffe00067115a0 stream 0 0 0 fffffe0006a595a0 0 0 /tmp/dbus-L2n5TYXqCj fffffe0006a595a0 stream 0 0 0 fffffe00067115a0 0 0 fffffe008364fd20 stream 0 0 0 fffffe008364fe10 0 0 /tmp/dbus-L2n5TYXqCj fffffe008364fe10 stream 0 0 0 fffffe008364fd20 0 0 fffffe00069230f0 stream 0 0 0 fffffe0006924000 0 0 /tmp/.X11-unix/X0 fffffe0006924000 stream 0 0 0 fffffe00069230f0 0 0 fffffe00835d0000 stream 0 0 0 fffffe00835d00f0 0 0 /tmp/.X11-unix/X0 fffffe00835d00f0 stream 0 0 0 fffffe00835d0000 0 0 fffffe00069482d0 stream 0 0 0 fffffe00069480f0 0 0 /tmp/dbus-L2n5TYXqCj fffffe00069480f0 stream 0 0 0 fffffe00069482d0 0 0 fffffe00069233c0 stream 0 0 0 fffffe0006a5a1e0 0 0 /tmp/.X11-unix/X0 fffffe0006a5a1e0 stream 0 0 0 fffffe00069233c0 0 0 fffffe00834d33c0 stream 0 0 0 fffffe00834d34b0 0 0 /tmp/dbus-L2n5TYXqCj fffffe00834d34b0 stream 0 0 0 fffffe00834d33c0 0 0 fffffe0006923690 stream 0 0 0 fffffe0006923780 0 0 /var/run/dbus/system_bus_socket fffffe0006923780 stream 0 0 0 fffffe0006923690 0 0 fffffe00834d35a0 stream 0 0 0 fffffe00834d3690 0 0 /var/run/devd.pipe fffffe00834d3690 stream 0 0 0 fffffe00834d35a0 0 0 fffffe0006a593c0 stream 0 0 0 fffffe0006973960 0 0 /tmp/dbus-L2n5TYXqCj fffffe0006973960 stream 0 0 0 fffffe0006a593c0 0 0 fffffe0006923870 stream 0 0 0 fffffe0006923960 0 0 fffffe0006923960 stream 0 0 0 fffffe0006923870 0 0 fffffe0006711780 stream 0 0 0 fffffe0006973780 0 0 /tmp/dbus-L2n5TYXqCj fffffe0006973780 stream 0 0 0 fffffe0006711780 0 0 fffffe00834d3870 stream 0 0 0 fffffe0006a5a2d0 0 0 /var/run/dbus/system_bus_socket fffffe0006a5a2d0 stream 0 0 0 fffffe00834d3870 0 0 fffffe000670a1e0 stream 0 0 0 fffffe00069273c0 0 0 /tmp/dbus-L2n5TYXqCj fffffe00069273c0 stream 0 0 0 fffffe000670a1e0 0 0 fffffe0006a590f0 stream 0 0 0 fffffe00069483c0 0 0 fffffe00069483c0 stream 0 0 0 fffffe0006a590f0 0 0 fffffe0006972a50 stream 0 0 0 fffffe0006973e10 0 0 /var/run/dbus/system_bus_socket fffffe0006973e10 stream 0 0 0 fffffe0006972a50 0 0 fffffe0006973c30 stream 0 0 0 fffffe0006973a50 0 0 /var/run/dbus/system_bus_socket fffffe0006973a50 stream 0 0 0 fffffe0006973c30 0 0 fffffe00835d01e0 stream 0 0 0 fffffe00835d02d0 0 0 /tmp/dbus-L2n5TYXqCj fffffe00835d02d0 stream 0 0 0 fffffe00835d01e0 0 0 fffffe00835d03c0 stream 0 0 0 fffffe00835d04b0 0 0 /tmp/dbus-L2n5TYXqCj fffffe00835d04b0 stream 0 0 0 fffffe00835d03c0 0 0 fffffe0006a59690 stream 0 0 0 fffffe0006711690 0 0 /tmp/dbus-L2n5TYXqCj fffffe0006711690 stream 0 0 0 fffffe0006a59690 0 0 fffffe000670a000 stream 0 0 0 fffffe000670a0f0 0 0 /var/run/dbus/system_bus_socket fffffe000670a0f0 stream 0 0 0 fffffe000670a000 0 0 fffffe00069481e0 stream 0 0 0 fffffe0006948000 0 0 /tmp/.ICE-unix/1450 fffffe0006948000 stream 0 0 0 fffffe00069481e0 0 0 fffffe0006972d20 stream 0 0 0 fffffe0006972b40 0 0 /tmp/dbus-L2n5TYXqCj fffffe0006972b40 stream 0 0 0 fffffe0006972d20 0 0 fffffe00834d3960 stream 0 0 0 fffffe00834d3a50 0 0 /tmp/.X11-unix/X0 fffffe00834d3a50 stream 0 0 0 fffffe00834d3960 0 0 fffffe000670b1e0 stream 0 0 0 fffffe000670b2d0 0 0 /tmp/.ICE-unix/1450 fffffe000670b2d0 stream 0 0 0 fffffe000670b1e0 0 0 fffffe000670ba50 stream 0 0 0 fffffe000670b690 0 0 /tmp/dbus-L2n5TYXqCj fffffe000670b690 stream 0 0 0 fffffe000670ba50 0 0 fffffe0006972960 stream 0 0 0 fffffe0006948d20 0 0 /tmp/.X11-unix/X0 fffffe0006948d20 stream 0 0 0 fffffe0006972960 0 0 fffffe00834d3b40 stream 0 0 0 fffffe00069271e0 0 0 /tmp/.ICE-unix/1450 fffffe00069271e0 stream 0 0 0 fffffe00834d3b40 0 0 fffffe0006927c30 stream 0 0 0 fffffe0006927b40 0 0 /tmp/dbus-L2n5TYXqCj fffffe0006927b40 stream 0 0 0 fffffe0006927c30 0 0 fffffe0006927a50 stream 0 0 0 fffffe0006927960 0 0 /tmp/.X11-unix/X0 fffffe0006927960 stream 0 0 0 fffffe0006927a50 0 0 fffffe0006927870 stream 0 0 0 fffffe0006927780 0 0 /tmp/.ICE-unix/1450 fffffe0006927780 stream 0 0 0 fffffe0006927870 0 0 fffffe0006923a50 stream 0 0 0 fffffe0006923b40 0 0 /tmp/dbus-L2n5TYXqCj fffffe0006923b40 stream 0 0 0 fffffe0006923a50 0 0 fffffe0006923e10 stream 0 0 0 fffffe000670a2d0 0 0 /tmp/.X11-unix/X0 fffffe000670a2d0 stream 0 0 0 fffffe0006923e10 0 0 fffffe00069243c0 stream 0 0 fffffe00831fc7e0 0 0 0 /tmp/gpg-kQy2Pa/S.gpg-agent.ssh fffffe0006972c30 stream 0 0 fffffe00831fc9d8 0 0 0 /tmp/gpg-SfIEPg/S.gpg-agent fffffe0006972780 stream 0 0 fffffe008330d9d8 0 0 0 /tmp/.ICE-unix/1450 fffffe00067111e0 stream 0 0 0 fffffe0006711000 0 0 /tmp/dbus-L2n5TYXqCj fffffe0006711000 stream 0 0 0 fffffe00067111e0 0 0 fffffe0006927e10 stream 0 0 0 fffffe0006972000 0 0 /tmp/dbus-L2n5TYXqCj fffffe0006972000 stream 0 0 0 fffffe0006927e10 0 0 fffffe00069720f0 stream 0 0 0 fffffe00069721e0 0 0 /tmp/.X11-unix/X0 fffffe00069721e0 stream 0 0 0 fffffe00069720f0 0 0 fffffe0006948e10 stream 0 0 0 fffffe0006948c30 0 0 /tmp/.X11-unix/X0 fffffe0006948c30 stream 0 0 0 fffffe0006948e10 0 0 fffffe00069735a0 stream 0 0 0 fffffe00069245a0 0 0 fffffe00069245a0 stream 0 0 0 fffffe00069735a0 0 0 fffffe0006923c30 stream 0 0 fffffe008323a000 0 0 0 /tmp/dbus-L2n5TYXqCj fffffe00069722d0 stream 0 0 0 fffffe00069723c0 0 0 /tmp/.X11-unix/X0 fffffe00069723c0 stream 0 0 0 fffffe00069722d0 0 0 fffffe00069724b0 stream 0 0 0 fffffe00069725a0 0 0 /var/run/dbus/system_bus_socket fffffe00069725a0 stream 0 0 0 fffffe00069724b0 0 0 fffffe000670be10 stream 0 0 0 fffffe000670bd20 0 0 /var/run/dbus/system_bus_socket fffffe000670bd20 stream 0 0 0 fffffe000670be10 0 0 fffffe00069240f0 stream 0 0 0 fffffe0006923d20 0 0 /tmp/.X11-unix/X0 fffffe0006923d20 stream 0 0 0 fffffe00069240f0 0 0 fffffe00069232d0 stream 0 0 0 fffffe00069231e0 0 0 /var/run/devd.pipe fffffe00069231e0 stream 0 0 0 fffffe00069232d0 0 0 fffffe0006a59000 stream 0 0 0 fffffe0006973870 0 0 /var/run/dbus/system_bus_socket fffffe0006973870 stream 0 0 0 fffffe0006a59000 0 0 fffffe0006973690 stream 0 0 0 fffffe00069734b0 0 0 /var/run/hald/dbus-FEIb7wRb6t fffffe00069734b0 stream 0 0 0 fffffe0006973690 0 0 fffffe000670bc30 stream 0 0 0 fffffe000670bb40 0 0 /var/run/hald/dbus-FEIb7wRb6t fffffe000670bb40 stream 0 0 0 fffffe000670bc30 0 0 fffffe000670a690 stream 0 0 fffffe0006d39bd0 0 0 0 /tmp/.X11-unix/X0 fffffe0006711a50 stream 0 0 0 fffffe0006711b40 0 0 /var/run/devd.pipe fffffe0006711b40 stream 0 0 0 fffffe0006711a50 0 0 fffffe0006924960 stream 0 0 0 fffffe0006924a50 0 0 /var/run/hald/dbus-w5rixTXvRk fffffe0006924a50 stream 0 0 0 fffffe0006924960 0 0 fffffe0006711c30 stream 0 0 fffffe0006ca2bd0 0 0 0 /var/run/hald/dbus-w5rixTXvRk fffffe0006924b40 stream 0 0 0 fffffe0006924c30 0 0 /var/run/dbus/system_bus_socket fffffe0006924c30 stream 0 0 0 fffffe0006924b40 0 0 fffffe0006924d20 stream 0 0 fffffe0006f9d7e0 0 0 0 /var/run/hald/dbus-FEIb7wRb6t fffffe000670b960 stream 0 0 0 fffffe000670b870 0 0 fffffe000670b870 stream 0 0 0 fffffe000670b960 0 0 fffffe0006927000 stream 0 0 0 fffffe00069270f0 0 0 /var/run/dbus/system_bus_socket fffffe00069270f0 stream 0 0 0 fffffe0006927000 0 0 fffffe000670a960 stream 0 0 0 fffffe000670aa50 0 0 /var/run/dbus/system_bus_socket fffffe000670aa50 stream 0 0 0 fffffe000670a960 0 0 fffffe0006a59960 stream 0 0 0 fffffe0006a59a50 0 0 /var/run/dbus/system_bus_socket fffffe0006a59a50 stream 0 0 0 fffffe0006a59960 0 0 fffffe0006a59e10 stream 0 0 0 fffffe0006a5a000 0 0 fffffe0006a5a000 stream 0 0 0 fffffe0006a59e10 0 0 fffffe000670ab40 stream 0 0 fffffe0006c5e1f8 0 0 0 /var/run/dbus/system_bus_socket fffffe0006711e10 stream 0 0 0 fffffe0006923000 0 0 /var/run/devd.pipe fffffe0006923000 stream 0 0 0 fffffe0006711e10 0 0 fffffe0006927d20 stream 0 0 fffffe0006926000 0 0 0 /var/run/devd.pipe fffffe00834d3e10 dgram 0 0 0 fffffe00069274b0 0 fffffe0083bca690 fffffe0006a5a3c0 dgram 0 0 fffffe00142c0000 0 0 0 /var/run/wpa_supplicant/wlan0 fffffe0083bca690 dgram 0 0 0 fffffe00069274b0 0 fffffe000670a780 fffffe0083e043c0 dgram 0 0 0 fffffe00069275a0 0 fffffe0006924e10 fffffe000670a780 dgram 0 0 0 fffffe00069274b0 0 fffffe0006711d20 fffffe0006924e10 dgram 0 0 0 fffffe00069275a0 0 fffffe0006a59d20 fffffe0006711d20 dgram 0 0 0 fffffe00069274b0 0 fffffe000670a870 fffffe000670a870 dgram 0 0 0 fffffe00069274b0 0 fffffe0006972e10 fffffe0006a59d20 dgram 0 0 0 fffffe00069275a0 0 fffffe000670ac30 fffffe000670ac30 dgram 0 0 0 fffffe00069275a0 0 0 fffffe0006972e10 dgram 0 0 0 fffffe00069274b0 0 fffffe000670b5a0 fffffe000670b5a0 dgram 0 0 0 fffffe00069274b0 0 0 fffffe00069274b0 dgram 0 0 fffffe00069549d8 0 fffffe00834d3e10 0 /var/run/logpriv fffffe00069275a0 dgram 0 0 fffffe0006954bd0 0 fffffe0083e043c0 0 /var/run/log ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 0/0/128 *.x11 tcp6 0/0/128 *.x11 tcp4 0/0/10 localhost.smtp tcp4 0/0/128 *.ssh tcp6 0/0/128 *.ssh unix 0/0/128 /tmp/.vbox-pacija-ipc/ipcd unix 0/0/128 /tmp/keyring-BRttYV/control unix 0/0/10 /tmp/orbit-pacija/linc-646-0-eb581dcabd06 unix 0/0/1 /tmp/sylpheed-1001 unix 0/0/5 /tmp/.org.chromium.Chromium.jZlfDS/SingletonSocket unix 0/0/10 /tmp/orbit-pacija/linc-5b9-0-4846a814db049 unix 0/0/10 /tmp/orbit-pacija/linc-5d4-0-7e5ceec686567 unix 0/0/5 /tmp/gpg-kQy2Pa/S.gpg-agent.ssh unix 0/0/5 /tmp/gpg-SfIEPg/S.gpg-agent unix 0/0/128 /tmp/.ICE-unix/1450 unix 0/0/30 /tmp/dbus-L2n5TYXqCj unix 0/0/128 /tmp/.X11-unix/X0 unix 0/0/30 /var/run/hald/dbus-w5rixTXvRk unix 0/0/30 /var/run/hald/dbus-FEIb7wRb6t unix 0/0/30 /var/run/dbus/system_bus_socket unix 0/0/4 /var/run/devd.pipe ------------------------------------------------------------------------ fstat USER CMD PID FD MOUNT INUM MODE SZ|DV R/W _dhcp dhclient 2286 root / 1284105 dr-xr-xr-x 512 r _dhcp dhclient 2286 wd / 1284105 dr-xr-xr-x 512 r _dhcp dhclient 2286 jail / 1284105 dr-xr-xr-x 512 r _dhcp dhclient 2286 text / 1847384 -r-xr-xr-x 96520 r _dhcp dhclient 2286 0 /dev 19 crw-rw-rw- null rw _dhcp dhclient 2286 1 /dev 19 crw-rw-rw- null rw _dhcp dhclient 2286 2 /dev 19 crw-rw-rw- null rw _dhcp dhclient 2286 3* local dgram fffffe00834d3e10 <-> fffffe00069274b0 _dhcp dhclient 2286 4 / 1284148 -rw------- 4 w _dhcp dhclient 2286 6* route raw 0 fffffe00aa1c8d48 _dhcp dhclient 2286 7* pipe fffffe00066f1708 <-> fffffe00066f15b0 0 rw _dhcp dhclient 2286 8 / 1284175 ---------- 1433 w _dhcp dhclient 2286 9 /dev 23 crw------- bpf rw _dhcp dhclient 2286 10* internet raw ip fffffe0020686000 root dhclient 2267 root / 2 drwxr-xr-x 1024 r root dhclient 2267 wd / 2 drwxr-xr-x 1024 r root dhclient 2267 text / 1847384 -r-xr-xr-x 96520 r root dhclient 2267 0 /dev 19 crw-rw-rw- null rw root dhclient 2267 1 /dev 19 crw-rw-rw- null rw root dhclient 2267 2 /dev 19 crw-rw-rw- null rw root dhclient 2267 3* local dgram fffffe00834d3e10 <-> fffffe00069274b0 root dhclient 2267 4 / 1284148 -rw------- 4 w root dhclient 2267 6* pipe fffffe00066f15b0 <-> fffffe00066f1708 0 rw root wpa_supplicant 2150 root / 2 drwxr-xr-x 1024 r root wpa_supplicant 2150 wd / 2 drwxr-xr-x 1024 r root wpa_supplicant 2150 text / 3070714 -r-xr-xr-x 373896 r root wpa_supplicant 2150 0 /dev 19 crw-rw-rw- null rw root wpa_supplicant 2150 1 /dev 19 crw-rw-rw- null rw root wpa_supplicant 2150 2 /dev 19 crw-rw-rw- null rw root wpa_supplicant 2150 3* local dgram fffffe0083bca690 <-> fffffe00069274b0 root wpa_supplicant 2150 4* internet dgram udp fffffe00066cbc40 root wpa_supplicant 2150 5* route raw 0 fffffe008302b2a8 root wpa_supplicant 2150 6 /dev 23 crw------- bpf rw root wpa_supplicant 2150 7* local dgram fffffe0006a5a3c0 pacija tcsh 2047 root / 2 drwxr-xr-x 1024 r pacija tcsh 2047 wd / 3131772 drwxr-xr-x 6656 r pacija tcsh 2047 text / 5698189 -r-xr-xr-x 382392 r pacija tcsh 2047 ctty /dev 132 crw--w---- pts/1 rw pacija tcsh 2047 15 /dev 132 crw--w---- pts/1 rw pacija tcsh 2047 16 /dev 132 crw--w---- pts/1 rw pacija tcsh 2047 17 /dev 132 crw--w---- pts/1 rw pacija tcsh 2047 18 /dev 132 crw--w---- pts/1 rw pacija tcsh 2047 19 /dev 132 crw--w---- pts/1 rw pacija chrome 2007 root / 2 drwxr-xr-x 1024 r pacija chrome 2007 wd / 3131772 drwxr-xr-x 6656 r pacija chrome 2007 text / 1311576 -r-xr-xr-x 83245104 r pacija chrome 2007 ctty /dev 47 crw------- ttyv1 rw pacija chrome 2007 0 /dev 19 crw-rw-rw- null r pacija chrome 2007 1 /dev 47 crw------- ttyv1 rw pacija chrome 2007 2 /dev 47 crw------- ttyv1 rw pacija chrome 2007 3* local stream fffffe00834d32d0 <-> fffffe00835d05a0 pacija chrome 2007 4 / 1311571 -r--r--r-- 4237426 r pacija chrome 2007 5 / 1311572 -r--r--r-- 880672 r pacija chrome 2007 6 / 2814041 -r--r--r-- 165391 r pacija chrome 2007 7 / 1311574 -r--r--r-- 5473882 r pacija chrome 2007 8 /dev 25 crw-rw-rw- random r pacija chrome 2007 10* pipe fffffe00206d2000 <-> fffffe00206d2158 0 rw pacija chrome 2007 11* pipe fffffe00206d2158 <-> fffffe00206d2000 0 rw pacija chrome 2007 12* local stream fffffe0083bcab40 <-> fffffe00069730f0 pacija chrome 2007 13* local stream fffffe00069730f0 <-> fffffe0083bcab40 pacija chrome 2007 14 - - ?(tmpfs) - pacija chrome 2007 15 - - ?(tmpfs) - pacija VBoxSVC 1933 root / 2 drwxr-xr-x 1024 r pacija VBoxSVC 1933 wd / 3131772 drwxr-xr-x 6656 r pacija VBoxSVC 1933 text / 4514132 -rwx--x--x 2835576 r pacija VBoxSVC 1933 0 /dev 19 crw-rw-rw- null rw pacija VBoxSVC 1933 1 /dev 19 crw-rw-rw- null rw pacija VBoxSVC 1933 2 /dev 19 crw-rw-rw- null rw pacija VBoxSVC 1933 3 / 4514122 drwxr-xr-x 1536 r pacija VBoxSVC 1933 4 / 4514122 drwxr-xr-x 1536 r pacija VBoxSVC 1933 5 / 4514122 drwxr-xr-x 1536 r pacija VBoxSVC 1933 6 / 4514123 drwxr-xr-x 512 r pacija VBoxSVC 1933 7 / 4735145 -rw------- 1539 w pacija VBoxSVC 1933 8* pipe fffffe0006530000 <-> fffffe0006530158 1 rw pacija VBoxSVC 1933 9* pipe fffffe0006530158 <-> fffffe0006530000 0 rw pacija VBoxSVC 1933 10* local stream fffffe0006924870 <-> fffffe0083e052d0 pacija VBoxSVC 1933 11* pipe fffffe00066e6888 <-> fffffe00066e69e0 0 rw pacija VBoxSVC 1933 12* pipe fffffe00066e69e0 <-> fffffe00066e6888 0 rw pacija VBoxSVC 1933 13 /dev 25 crw-rw-rw- random r pacija VBoxSVC 1933 14 / 4514122 drwxr-xr-x 1536 r pacija VBoxSVC 1933 15* pipe fffffe0020f155b0 <-> fffffe0020f15708 0 rw pacija VBoxSVC 1933 16* pipe fffffe0020f15708 <-> fffffe0020f155b0 0 rw pacija VBoxXPCOMIPCD 1931 root / 2 drwxr-xr-x 1024 r pacija VBoxXPCOMIPCD 1931 wd / 3131772 drwxr-xr-x 6656 r pacija VBoxXPCOMIPCD 1931 text / 4514127 -rwx--x--x 28896 r pacija VBoxXPCOMIPCD 1931 0 /dev 19 crw-rw-rw- null rw pacija VBoxXPCOMIPCD 1931 1 /dev 19 crw-rw-rw- null rw pacija VBoxXPCOMIPCD 1931 2 /dev 19 crw-rw-rw- null rw pacija VBoxXPCOMIPCD 1931 3 / 4514122 drwxr-xr-x 1536 r pacija VBoxXPCOMIPCD 1931 4 / 4514122 drwxr-xr-x 1536 r pacija VBoxXPCOMIPCD 1931 5 / 4514122 drwxr-xr-x 1536 r pacija VBoxXPCOMIPCD 1931 6 / 4514123 drwxr-xr-x 512 r pacija VBoxXPCOMIPCD 1931 7 - - ?(tmpfs) - pacija VBoxXPCOMIPCD 1931 8* local stream fffffe0083e040f0 pacija VBoxXPCOMIPCD 1931 9* local stream fffffe00834d3d20 <-> fffffe0083ea8780 pacija VBoxXPCOMIPCD 1931 10* local stream fffffe0083e052d0 <-> fffffe0006924870 pacija VirtualBox 1929 root / 2 drwxr-xr-x 1024 r pacija VirtualBox 1929 wd / 3131772 drwxr-xr-x 6656 r pacija VirtualBox 1929 text / 4514143 -r-s--x--x 28024 r pacija VirtualBox 1929 ctty /dev 47 crw------- ttyv1 rw pacija VirtualBox 1929 0 /dev 19 crw-rw-rw- null r pacija VirtualBox 1929 1 /dev 47 crw------- ttyv1 rw pacija VirtualBox 1929 2 /dev 47 crw------- ttyv1 rw pacija VirtualBox 1929 3 / 4514122 drwxr-xr-x 1536 r pacija VirtualBox 1929 4 / 4514122 drwxr-xr-x 1536 r pacija VirtualBox 1929 5 / 4514122 drwxr-xr-x 1536 r pacija VirtualBox 1929 6 / 4514123 drwxr-xr-x 512 r pacija VirtualBox 1929 7 /dev 65 crw------- vboxdrv rw pacija VirtualBox 1929 8 /dev 25 crw-rw-rw- random r pacija VirtualBox 1929 9* local stream fffffe0083f58960 <-> fffffe0083e05000 pacija VirtualBox 1929 10* pipe fffffe006416fb60 <-> fffffe006416fcb8 0 rw pacija VirtualBox 1929 11* pipe fffffe006416fcb8 <-> fffffe006416fb60 0 rw pacija VirtualBox 1929 12* pipe fffffe00206d2888 <-> fffffe00206d29e0 4 rw pacija VirtualBox 1929 13* pipe fffffe00206d29e0 <-> fffffe00206d2888 0 rw pacija VirtualBox 1929 14* local stream fffffe0083ad94b0 <-> fffffe00069234b0 pacija VirtualBox 1929 15* pipe fffffe00832995b0 <-> fffffe0083299708 0 rw pacija VirtualBox 1929 16* pipe fffffe0083299708 <-> fffffe00832995b0 0 rw pacija VirtualBox 1929 17* local stream fffffe0083ea8780 <-> fffffe00834d3d20 pacija VirtualBox 1929 18* pipe fffffe006416f888 <-> fffffe006416f9e0 0 rw pacija VirtualBox 1929 19* pipe fffffe006416f9e0 <-> fffffe006416f888 0 rw pacija VirtualBox 1929 20 /media/share -1765527641 -rwxr-xr-x 79403 w pacija VirtualBox 1929 21* local stream fffffe0083e04000 <-> fffffe0083e05c30 pacija VirtualBox 1929 22 /dev 35 crw-rw-rw- nvidiactl rw pacija VirtualBox 1929 23 /dev 34 crw-rw-rw- nvidia0 rw pacija VirtualBox 1929 24 /dev 34 crw-rw-rw- nvidia0 rw pacija VirtualBox 1929 25 /dev 34 crw-rw-rw- nvidia0 rw pacija VirtualBox 1929 26 /dev 34 crw-rw-rw- nvidia0 rw pacija VirtualBox 1929 27 / 3692029 -rw-r--r-- 116 rw pacija VirtualBox 1929 28 / 3692030 -rw-r--r-- 728 rw pacija VirtualBox 1929 29 / 2414050 -r--r--r-- 548315 r pacija VirtualBox 1929 30 / 2414319 -r--r--r-- 144749 r pacija VirtualBox 1929 31 / 2414329 -r--r--r-- 18576 r pacija VirtualBox 1929 32 /media/share -1765528662 -rwxr-xr-x 1029 rw pacija VirtualBox 1929 33 /media/share -1765528659 -rwxr-xr-x 2127101952 rw pacija VirtualBox 1929 34 /media/share -1765528656 -rwxr-xr-x 2120220672 rw pacija VirtualBox 1929 35 /media/share -1765528653 -rwxr-xr-x 2109079552 rw pacija VirtualBox 1929 36 /media/share -1765528650 -rwxr-xr-x 2101084160 rw pacija VirtualBox 1929 37 /media/share -1765528647 -rwxr-xr-x 2138832896 rw pacija VirtualBox 1929 38 /media/share -1765528644 -rwxr-xr-x 2145386496 rw pacija VirtualBox 1929 39 /media/share -1765528641 -rwxr-xr-x 2111700992 rw pacija VirtualBox 1929 40 /media/share -1765528638 -rwxr-xr-x 1987772416 rw pacija VirtualBox 1929 41 /media/share -1765528635 -rwxr-xr-x 1879900160 rw pacija VirtualBox 1929 42 /media/share -1765528632 -rwxr-xr-x 1604190208 rw pacija VirtualBox 1929 43 /media/share -1765528629 -rwxr-xr-x 131072 rw pacija VirtualBox 1929 44 /dev 122 crw-rw-rw- dsp4.0 r pacija VirtualBox 1929 45 /dev 129 crw-rw-rw- dsp4.1 w pacija VirtualBox 1929 46 /dev 34 crw-rw-rw- nvidia0 rw pacija VirtualBox 1929 47 /dev 34 crw-rw-rw- nvidia0 rw pacija VirtualBox 1929 48* local stream fffffe0083e05d20 <-> fffffe0006924690 pacija VirtualBox 1929 49* pipe fffffe00640a02d8 <-> fffffe00640a0430 0 rw pacija VirtualBox 1929 50* pipe fffffe00640a0430 <-> fffffe00640a02d8 0 rw pacija VirtualBox 1929 51* local stream fffffe0083e0cd20 <-> fffffe0083ea90f0 pacija tcsh 1866 root / 2 drwxr-xr-x 1024 r pacija tcsh 1866 wd / 3131772 drwxr-xr-x 6656 r pacija tcsh 1866 text / 5698189 -r-xr-xr-x 382392 r pacija tcsh 1866 ctty /dev 136 crw--w---- pts/4 rw pacija tcsh 1866 15 /dev 136 crw--w---- pts/4 rw pacija tcsh 1866 16 /dev 136 crw--w---- pts/4 rw pacija tcsh 1866 17 /dev 136 crw--w---- pts/4 rw pacija tcsh 1866 18 /dev 136 crw--w---- pts/4 rw pacija tcsh 1866 19 /dev 136 crw--w---- pts/4 rw pacija chrome 1834 root / 2 drwxr-xr-x 1024 r pacija chrome 1834 wd / 3131772 drwxr-xr-x 6656 r pacija chrome 1834 text / 1311576 -r-xr-xr-x 83245104 r pacija chrome 1834 ctty /dev 47 crw------- ttyv1 rw pacija chrome 1834 0 /dev 19 crw-rw-rw- null r pacija chrome 1834 1 /dev 47 crw------- ttyv1 rw pacija chrome 1834 2 /dev 47 crw------- ttyv1 rw pacija chrome 1834 3* local stream fffffe0006924780 <-> fffffe0083e04c30 pacija chrome 1834 4 / 1311571 -r--r--r-- 4237426 r pacija chrome 1834 5 / 1311572 -r--r--r-- 880672 r pacija chrome 1834 6 / 2814041 -r--r--r-- 165391 r pacija chrome 1834 7 / 1311574 -r--r--r-- 5473882 r pacija chrome 1834 8 /dev 25 crw-rw-rw- random r pacija chrome 1834 10* pipe fffffe00831292d8 <-> fffffe0083129430 0 rw pacija chrome 1834 11* pipe fffffe0083129430 <-> fffffe00831292d8 0 rw pacija chrome 1834 12* local stream fffffe0083bcaa50 <-> fffffe0083ea81e0 pacija chrome 1834 13* local stream fffffe0083ea81e0 <-> fffffe0083bcaa50 pacija chrome 1834 14 - - ?(tmpfs) - pacija chrome 1834 15 - - ?(tmpfs) - pacija ssh 1829 root / 2 drwxr-xr-x 1024 r pacija ssh 1829 wd / 3131772 drwxr-xr-x 6656 r pacija ssh 1829 text / 3055113 -r-xr-xr-x 171984 r pacija ssh 1829 ctty /dev 135 crw--w---- pts/3 rw pacija ssh 1829 0 /dev 135 crw--w---- pts/3 rw pacija ssh 1829 1 /dev 135 crw--w---- pts/3 rw pacija ssh 1829 2 /dev 135 crw--w---- pts/3 rw pacija ssh 1829 3* internet stream tcp fffffe00640387a0 pacija ssh 1829 4 /dev 135 crw--w---- pts/3 rw pacija ssh 1829 5 /dev 135 crw--w---- pts/3 rw pacija ssh 1829 6 /dev 135 crw--w---- pts/3 rw pacija tcsh 1826 root / 2 drwxr-xr-x 1024 r pacija tcsh 1826 wd / 3131772 drwxr-xr-x 6656 r pacija tcsh 1826 text / 5698189 -r-xr-xr-x 382392 r pacija tcsh 1826 ctty /dev 135 crw--w---- pts/3 rw pacija tcsh 1826 15 /dev 135 crw--w---- pts/3 rw pacija tcsh 1826 16 /dev 135 crw--w---- pts/3 rw pacija tcsh 1826 17 /dev 135 crw--w---- pts/3 rw pacija tcsh 1826 18 /dev 135 crw--w---- pts/3 rw pacija tcsh 1826 19 /dev 135 crw--w---- pts/3 rw pacija chrome 1823 root / 2 drwxr-xr-x 1024 r pacija chrome 1823 wd / 3131772 drwxr-xr-x 6656 r pacija chrome 1823 text / 1311576 -r-xr-xr-x 83245104 r pacija chrome 1823 ctty /dev 47 crw------- ttyv1 rw pacija chrome 1823 0 /dev 19 crw-rw-rw- null r pacija chrome 1823 1 /dev 47 crw------- ttyv1 rw pacija chrome 1823 2 /dev 47 crw------- ttyv1 rw pacija chrome 1823 3* local stream fffffe00835d0e10 <-> fffffe0006a59780 pacija chrome 1823 4 / 1311571 -r--r--r-- 4237426 r pacija chrome 1823 5 / 1311572 -r--r--r-- 880672 r pacija chrome 1823 6 / 2814041 -r--r--r-- 165391 r pacija chrome 1823 7 / 1311574 -r--r--r-- 5473882 r pacija chrome 1823 8 /dev 25 crw-rw-rw- random r pacija chrome 1823 10* pipe fffffe00064292d8 <-> fffffe0006429430 0 rw pacija chrome 1823 11* pipe fffffe0006429430 <-> fffffe00064292d8 0 rw pacija chrome 1823 12* local stream fffffe0083ada3c0 <-> fffffe0083ada4b0 pacija chrome 1823 13* local stream fffffe0083ada4b0 <-> fffffe0083ada3c0 pacija chrome 1823 14 - - ?(tmpfs) - pacija chrome 1823 15 - - ?(tmpfs) - pacija chrome 1695 root / 2 drwxr-xr-x 1024 r pacija chrome 1695 wd / 3131772 drwxr-xr-x 6656 r pacija chrome 1695 text / 1311576 -r-xr-xr-x 83245104 r pacija chrome 1695 ctty /dev 47 crw------- ttyv1 rw pacija chrome 1695 0 /dev 19 crw-rw-rw- null r pacija chrome 1695 1 /dev 47 crw------- ttyv1 rw pacija chrome 1695 2 /dev 47 crw------- ttyv1 rw pacija chrome 1695 3* local stream fffffe0006948b40 <-> fffffe00835d0a50 pacija chrome 1695 4 / 1311571 -r--r--r-- 4237426 r pacija chrome 1695 5 / 1311572 -r--r--r-- 880672 r pacija chrome 1695 6 / 2814041 -r--r--r-- 165391 r pacija chrome 1695 7 / 1311574 -r--r--r-- 5473882 r pacija chrome 1695 8 /dev 25 crw-rw-rw- random r pacija chrome 1695 10* pipe fffffe00206d4888 <-> fffffe00206d49e0 0 rw pacija chrome 1695 11* pipe fffffe00206d49e0 <-> fffffe00206d4888 0 rw pacija chrome 1695 12* local stream fffffe0083e0cc30 <-> fffffe0083e0c690 pacija chrome 1695 13* local stream fffffe0083e0c690 <-> fffffe0083e0cc30 pacija chrome 1695 14 - - ?(tmpfs) - pacija chrome 1695 15 - - ?(tmpfs) - pacija gnome-keyring-daem 1672 root / 2 drwxr-xr-x 1024 r pacija gnome-keyring-daem 1672 wd / 2 drwxr-xr-x 1024 r pacija gnome-keyring-daem 1672 text / 3291144 -r-xr-xr-x 849464 r pacija gnome-keyring-daem 1672 0 /dev 19 crw-rw-rw- null rw pacija gnome-keyring-daem 1672 1 /dev 19 crw-rw-rw- null rw pacija gnome-keyring-daem 1672 2 /dev 19 crw-rw-rw- null rw pacija gnome-keyring-daem 1672 3 /dev 25 crw-rw-rw- random r pacija gnome-keyring-daem 1672 4* local stream fffffe0083e053c0 <-> fffffe0006711960 pacija gnome-keyring-daem 1672 5 / 2970888 drwxr-xr-x 512 r pacija gnome-keyring-daem 1672 6 / 2752538 drwxr-xr-x 512 r pacija gnome-keyring-daem 1672 7 / 3936387 drwxr-xr-x 1536 r pacija gnome-keyring-daem 1672 8 / 3936387 drwxr-xr-x 1536 r pacija gnome-keyring-daem 1672 9* pipe fffffe00065352d8 <-> fffffe0006535430 0 rw pacija gnome-keyring-daem 1672 10* pipe fffffe0006535430 <-> fffffe00065352d8 0 rw pacija gnome-keyring-daem 1672 11* local stream fffffe0083e05e10 pacija gnome-keyring-daem 1672 12* pipe fffffe0006694000 <-> fffffe0006694158 0 rw pacija gnome-keyring-daem 1672 13* pipe fffffe0006694158 <-> fffffe0006694000 0 rw pacija gnome-keyring-daem 1672 14* local stream fffffe0083e045a0 <-> fffffe0083e044b0 pacija gnome-keyring-daem 1672 15* pipe fffffe0083365b60 <-> fffffe0083365cb8 0 rw pacija gnome-keyring-daem 1672 16* pipe fffffe0083365cb8 <-> fffffe0083365b60 0 rw pacija gnome-keyring-daem 1672 17* pipe fffffe0083122b60 <-> fffffe0083122cb8 0 rw pacija gnome-keyring-daem 1672 18* pipe fffffe0083122cb8 <-> fffffe0083122b60 0 rw pacija gnome-keyring-daem 1672 19* local dgram fffffe0083e043c0 <-> fffffe00069275a0 pacija gnome-keyring-daem 1672 20* pipe fffffe002088e888 <-> fffffe002088e9e0 0 rw pacija gnome-keyring-daem 1672 21* pipe fffffe002088e9e0 <-> fffffe002088e888 0 rw pacija chrome 1669 root / 2 drwxr-xr-x 1024 r pacija chrome 1669 wd / 3131772 drwxr-xr-x 6656 r pacija chrome 1669 text / 1311576 -r-xr-xr-x 83245104 r pacija chrome 1669 ctty /dev 47 crw------- ttyv1 rw pacija chrome 1669 0 /dev 19 crw-rw-rw- null r pacija chrome 1669 1 /dev 47 crw------- ttyv1 rw pacija chrome 1669 2 /dev 47 crw------- ttyv1 rw pacija chrome 1669 3* local stream fffffe0083ada5a0 <-> fffffe0083ada690 pacija chrome 1669 4 / 1311571 -r--r--r-- 4237426 r pacija chrome 1669 5 / 1311572 -r--r--r-- 880672 r pacija chrome 1669 6 / 2814041 -r--r--r-- 165391 r pacija chrome 1669 7 / 1311574 -r--r--r-- 5473882 r pacija chrome 1669 8 /dev 25 crw-rw-rw- random r pacija chrome 1669 10* pipe fffffe0083366000 <-> fffffe0083366158 0 rw pacija chrome 1669 11* pipe fffffe0083366158 <-> fffffe0083366000 0 rw pacija chrome 1669 12* local stream fffffe0083e0c0f0 <-> fffffe0083e0c000 pacija chrome 1669 13* local stream fffffe0083e0c000 <-> fffffe0083e0c0f0 pacija chrome 1669 14 - - ?(tmpfs) - pacija chrome 1669 15 - - ?(tmpfs) - pacija remmina 1665 root / 2 drwxr-xr-x 1024 r pacija remmina 1665 wd / 3131772 drwxr-xr-x 6656 r pacija remmina 1665 text / 3296231 -rwxr-xr-x 289656 r pacija remmina 1665 ctty /dev 47 crw------- ttyv1 rw pacija remmina 1665 0 /dev 19 crw-rw-rw- null r pacija remmina 1665 1 /dev 47 crw------- ttyv1 rw pacija remmina 1665 2 /dev 47 crw------- ttyv1 rw pacija remmina 1665 3* local stream fffffe00835d0780 <-> fffffe0083ea80f0 pacija remmina 1665 4* pipe fffffe00065355b0 <-> fffffe0006535708 0 rw pacija remmina 1665 5* pipe fffffe0006535708 <-> fffffe00065355b0 0 rw pacija remmina 1665 6* local stream fffffe0083f583c0 <-> fffffe0083f585a0 pacija remmina 1665 7* pipe fffffe0006694888 <-> fffffe00066949e0 0 rw pacija remmina 1665 8* pipe fffffe00066949e0 <-> fffffe0006694888 0 rw pacija remmina 1665 9* pipe fffffe008327f888 <-> fffffe008327f9e0 0 rw pacija remmina 1665 10* pipe fffffe008327f9e0 <-> fffffe008327f888 0 rw pacija remmina 1665 11* local stream fffffe0006711870 <-> fffffe0006a592d0 pacija remmina 1665 12* pipe fffffe00832992d8 <-> fffffe0083299430 0 rw pacija remmina 1665 13* pipe fffffe0083299430 <-> fffffe00832992d8 0 rw pacija remmina 1665 14* pipe fffffe008396b2d8 <-> fffffe008396b430 0 rw pacija remmina 1665 15* pipe fffffe008396b430 <-> fffffe008396b2d8 0 rw pacija remmina 1665 19* pipe fffffe00206d4000 <-> fffffe00206d4158 0 rw pacija remmina 1665 20* pipe fffffe00206d4158 <-> fffffe00206d4000 0 rw pacija remmina 1665 21* pipe fffffe00206d3b60 <-> fffffe00206d3cb8 0 rw pacija remmina 1665 22* pipe fffffe00206d3cb8 <-> fffffe00206d3b60 0 rw pacija remmina 1665 23* pipe fffffe008327f2d8 <-> fffffe008327f430 0 rw pacija remmina 1665 24* pipe fffffe008327f430 <-> fffffe008327f2d8 0 rw pacija remmina 1665 25* pipe fffffe00065672d8 <-> fffffe0006567430 0 rw pacija remmina 1665 26* pipe fffffe0006567430 <-> fffffe00065672d8 0 rw pacija remmina 1665 27* pipe fffffe002088e5b0 <-> fffffe002088e708 0 rw pacija remmina 1665 28* pipe fffffe002088e708 <-> fffffe002088e5b0 0 rw pacija remmina 1665 29* local stream fffffe0083ea8a50 <-> fffffe0083f58c30 pacija remmina 1665 30 /dev 25 crw-rw-rw- random r pacija remmina 1665 31* pipe fffffe0083129888 <-> fffffe00831299e0 0 rw pacija remmina 1665 32* pipe fffffe00206d3888 <-> fffffe00206d39e0 0 rw pacija remmina 1665 33* pipe fffffe00206d39e0 <-> fffffe00206d3888 0 rw pacija remmina 1665 34* pipe fffffe00206d35b0 <-> fffffe00206d3708 0 rw pacija remmina 1665 35* pipe fffffe00206d3708 <-> fffffe00206d35b0 0 rw pacija remmina 1665 36* pipe fffffe00831299e0 <-> fffffe0083129888 0 rw pacija remmina 1665 37* pipe fffffe002088eb60 <-> fffffe002088ecb8 0 rw pacija remmina 1665 38* pipe fffffe002088ecb8 <-> fffffe002088eb60 0 rw pacija remmina 1665 39* internet stream tcp fffffe00aa27eb70 pacija remmina 1665 40* pipe fffffe0083299b60 <-> fffffe0083299cb8 0 rw pacija remmina 1665 41* pipe fffffe0083299cb8 <-> fffffe0083299b60 0 rw pacija remmina 1665 42* pipe fffffe008327e000 <-> fffffe008327e158 0 rw pacija remmina 1665 43* pipe fffffe008327e158 <-> fffffe008327e000 0 rw pacija tcsh 1662 root / 2 drwxr-xr-x 1024 r pacija tcsh 1662 wd / 3131772 drwxr-xr-x 6656 r pacija tcsh 1662 text / 5698189 -r-xr-xr-x 382392 r pacija tcsh 1662 ctty /dev 134 crw--w---- pts/2 rw pacija tcsh 1662 15 /dev 134 crw--w---- pts/2 rw pacija tcsh 1662 16 /dev 134 crw--w---- pts/2 rw pacija tcsh 1662 17 /dev 134 crw--w---- pts/2 rw pacija tcsh 1662 18 /dev 134 crw--w---- pts/2 rw pacija tcsh 1662 19 /dev 134 crw--w---- pts/2 rw pacija tcsh 1608 root / 2 drwxr-xr-x 1024 r pacija tcsh 1608 wd / 3131772 drwxr-xr-x 6656 r pacija tcsh 1608 text / 5698189 -r-xr-xr-x 382392 r pacija tcsh 1608 ctty /dev 126 crw--w---- pts/0 rw pacija tcsh 1608 15 /dev 126 crw--w---- pts/0 rw pacija tcsh 1608 16 /dev 126 crw--w---- pts/0 rw pacija tcsh 1608 17 /dev 126 crw--w---- pts/0 rw pacija tcsh 1608 18 /dev 126 crw--w---- pts/0 rw pacija tcsh 1608 19 /dev 126 crw--w---- pts/0 rw root gnome-pty-helper 1607 root / 2 drwxr-xr-x 1024 r root gnome-pty-helper 1607 wd / 2 drwxr-xr-x 1024 r root gnome-pty-helper 1607 text / 3780721 -r-sr-xr-x 14008 r root gnome-pty-helper 1607 ctty /dev 47 crw------- ttyv1 rw root gnome-pty-helper 1607 0* local stream fffffe0083ea8690 <-> fffffe0083ea82d0 root gnome-pty-helper 1607 1* local stream fffffe0083ea8690 <-> fffffe0083ea82d0 root gnome-pty-helper 1607 2 /dev 19 crw-rw-rw- null rw pacija gnome-terminal 1606 root / 2 drwxr-xr-x 1024 r pacija gnome-terminal 1606 wd / 3131772 drwxr-xr-x 6656 r pacija gnome-terminal 1606 text / 3292958 -r-xr-xr-x 312856 r pacija gnome-terminal 1606 ctty /dev 47 crw------- ttyv1 rw pacija gnome-terminal 1606 0 /dev 19 crw-rw-rw- null r pacija gnome-terminal 1606 1 /dev 47 crw------- ttyv1 rw pacija gnome-terminal 1606 2 /dev 47 crw------- ttyv1 rw pacija gnome-terminal 1606 3* local stream fffffe0083e0de10 <-> fffffe0083e0dd20 pacija gnome-terminal 1606 4* pipe fffffe00066f1000 <-> fffffe00066f1158 0 rw pacija gnome-terminal 1606 5* pipe fffffe00066f1158 <-> fffffe00066f1000 0 rw pacija gnome-terminal 1606 6* local stream fffffe0083e0dc30 <-> fffffe0083e0db40 pacija gnome-terminal 1606 7* local stream fffffe00835d0960 <-> fffffe00835d0870 pacija gnome-terminal 1606 8* pipe fffffe0006447000 <-> fffffe0006447158 0 rw pacija gnome-terminal 1606 9* pipe fffffe0006447158 <-> fffffe0006447000 0 rw pacija gnome-terminal 1606 10* pipe fffffe000668db60 <-> fffffe000668dcb8 0 rw pacija gnome-terminal 1606 11* pipe fffffe000668dcb8 <-> fffffe000668db60 0 rw pacija gnome-terminal 1606 12* pipe fffffe00065abb60 <-> fffffe00065abcb8 0 rw pacija gnome-terminal 1606 13* pipe fffffe00065abcb8 <-> fffffe00065abb60 0 rw pacija gnome-terminal 1606 14* pipe fffffe00065675b0 <-> fffffe0006567708 0 rw pacija gnome-terminal 1606 15* pipe fffffe0006567708 <-> fffffe00065675b0 0 rw pacija gnome-terminal 1606 16* local stream fffffe0083e0da50 <-> fffffe0083e0d960 pacija gnome-terminal 1606 17* local stream fffffe0083e0d870 pacija gnome-terminal 1606 18* local stream fffffe0083bca4b0 <-> fffffe0083bca5a0 pacija gnome-terminal 1606 19* local stream fffffe0083e0c4b0 <-> fffffe0083e0c3c0 pacija gnome-terminal 1606 20* pseudo-terminal master pts/0 rw pacija gnome-terminal 1606 21 /dev 126 crw--w---- pts/0 rw pacija gnome-terminal 1606 22* local stream fffffe0083ea82d0 <-> fffffe0083ea8690 pacija gnome-terminal 1606 23* pipe fffffe0083122000 <-> fffffe0083122158 0 rw pacija gnome-terminal 1606 24* pipe fffffe0083122158 <-> fffffe0083122000 0 rw pacija gnome-terminal 1606 25* pseudo-terminal master pts/2 rw pacija gnome-terminal 1606 26 /dev 134 crw--w---- pts/2 rw pacija gnome-terminal 1606 27* pseudo-terminal master pts/3 rw pacija gnome-terminal 1606 28 - - ?(tmpfs) - pacija gnome-terminal 1606 29 - - ?(tmpfs) - pacija gnome-terminal 1606 30 /dev 135 crw--w---- pts/3 rw pacija gnome-terminal 1606 31* pseudo-terminal master pts/4 rw pacija gnome-terminal 1606 32 - - ?(tmpfs) - pacija gnome-terminal 1606 33 - - ?(tmpfs) - pacija gnome-terminal 1606 34 - - ?(tmpfs) - pacija gnome-terminal 1606 35 /dev 136 crw--w---- pts/4 rw pacija gnome-terminal 1606 36* pseudo-terminal master pts/1 rw pacija gnome-terminal 1606 37 - - ?(tmpfs) - pacija gnome-terminal 1606 38 - - ?(tmpfs) - pacija gnome-terminal 1606 39 /dev 132 crw--w---- pts/1 rw pacija gnome-terminal 1606 41 - - ?(tmpfs) - pacija gnome-terminal 1606 42 - - ?(tmpfs) - pacija gnome-terminal 1606 43 - - ?(tmpfs) - pacija chrome 1602 root / 2 drwxr-xr-x 1024 r pacija chrome 1602 wd / 3131772 drwxr-xr-x 6656 r pacija chrome 1602 text / 1311576 -r-xr-xr-x 83245104 r pacija chrome 1602 ctty /dev 47 crw------- ttyv1 rw pacija chrome 1602 0 /dev 19 crw-rw-rw- null r pacija chrome 1602 1 /dev 47 crw------- ttyv1 rw pacija chrome 1602 2 /dev 47 crw------- ttyv1 rw pacija chrome 1602 3* local stream fffffe00835d0c30 <-> fffffe00835d0d20 pacija chrome 1602 5* pipe fffffe008396a000 <-> fffffe008396a158 0 rw pacija chrome 1602 6* pipe fffffe008396a158 <-> fffffe008396a000 0 rw pacija chrome 1602 7 /dev 25 crw-rw-rw- random r pacija chrome 1602 8 / 5059383 -rw------- 9216 rw pacija chrome 1602 9 / 5059385 -rw------- 11264 rw pacija chrome 1602 10* local stream fffffe0083ea9960 <-> fffffe0083ea9870 pacija chrome 1602 11* local stream fffffe0083ea9780 <-> fffffe0083ad9000 pacija chrome 1602 12 /dev 35 crw-rw-rw- nvidiactl rw pacija chrome 1602 13 /dev 34 crw-rw-rw- nvidia0 rw pacija chrome 1602 14 /dev 34 crw-rw-rw- nvidia0 rw pacija chrome 1602 15 /dev 34 crw-rw-rw- nvidia0 rw pacija chrome 1602 16 /dev 34 crw-rw-rw- nvidia0 rw pacija chrome 1602 17 / 3718283 -rw-r--r-- 2868 rw pacija chrome 1602 18 / 3718284 -rw-r--r-- 65642 rw pacija chrome 1602 20* pipe fffffe008327fb60 <-> fffffe008327fcb8 0 rw pacija chrome 1602 21* pipe fffffe008327fcb8 <-> fffffe008327fb60 0 rw pacija chrome 1602 22* local stream fffffe0083e04a50 <-> fffffe0083e04960 pacija chrome 1602 23* local stream fffffe0083e04960 <-> fffffe0083e04a50 pacija sylpheed 1590 root / 2 drwxr-xr-x 1024 r pacija sylpheed 1590 wd / 3131772 drwxr-xr-x 6656 r pacija sylpheed 1590 text / 3296671 -r-xr-xr-x 1192456 r pacija sylpheed 1590 ctty /dev 47 crw------- ttyv1 rw pacija sylpheed 1590 0 /dev 19 crw-rw-rw- null r pacija sylpheed 1590 1 /dev 47 crw------- ttyv1 rw pacija sylpheed 1590 2 /dev 47 crw------- ttyv1 rw pacija sylpheed 1590 3* local stream fffffe0083ea85a0 pacija sylpheed 1590 4* local stream fffffe0083ea84b0 <-> fffffe0083ea83c0 pacija sylpheed 1590 5* pipe fffffe008310d888 <-> fffffe008310d9e0 0 rw pacija sylpheed 1590 6* pipe fffffe008310d9e0 <-> fffffe008310d888 0 rw pacija sylpheed 1590 7 / 3132137 -rw-r--r-- 106606 w pacija sylpheed 1590 8* local stream fffffe0083ea9b40 <-> fffffe0083ea9a50 pacija sylpheed 1590 9* internet stream tcp fffffe0006bc1b70 pacija sylpheed 1590 10* pipe fffffe008396b5b0 <-> fffffe008396b708 0 rw pacija sylpheed 1590 11* pipe fffffe008396b708 <-> fffffe008396b5b0 0 rw pacija chrome 1552 root / 2 drwxr-xr-x 1024 r pacija chrome 1552 wd / 3131772 drwxr-xr-x 6656 r pacija chrome 1552 text / 1311576 -r-xr-xr-x 83245104 r pacija chrome 1552 ctty /dev 47 crw------- ttyv1 rw pacija chrome 1552 0 /dev 19 crw-rw-rw- null r pacija chrome 1552 1 /dev 47 crw------- ttyv1 rw pacija chrome 1552 2 /dev 47 crw------- ttyv1 rw pacija chrome 1552 3* local stream fffffe0083ad91e0 <-> fffffe0083ad92d0 pacija chrome 1552 4 / 1311571 -r--r--r-- 4237426 r pacija chrome 1552 5 / 1311572 -r--r--r-- 880672 r pacija chrome 1552 6 / 2814041 -r--r--r-- 165391 r pacija chrome 1552 7 / 1311574 -r--r--r-- 5473882 r pacija chrome 1552 8 /dev 25 crw-rw-rw- random r pacija chrome 1552 10* pipe fffffe008396ab60 <-> fffffe008396acb8 0 rw pacija chrome 1552 11* pipe fffffe008396acb8 <-> fffffe008396ab60 0 rw pacija chrome 1552 12* local stream fffffe0083f58d20 <-> fffffe000670a3c0 pacija chrome 1552 13* local stream fffffe000670a3c0 <-> fffffe0083f58d20 pacija chrome 1552 14 - - ?(tmpfs) - pacija chrome 1552 15 - - ?(tmpfs) - pacija chrome 1549 root / 2 drwxr-xr-x 1024 r pacija chrome 1549 wd / 3131772 drwxr-xr-x 6656 r pacija chrome 1549 text / 1311576 -r-xr-xr-x 83245104 r pacija chrome 1549 ctty /dev 47 crw------- ttyv1 rw pacija chrome 1549 0 /dev 19 crw-rw-rw- null r pacija chrome 1549 1 /dev 47 crw------- ttyv1 rw pacija chrome 1549 2 /dev 47 crw------- ttyv1 rw pacija chrome 1549 3* local stream fffffe0083ea9000 <-> fffffe0083ea8e10 pacija chrome 1549 4* pipe fffffe0083366888 <-> fffffe00833669e0 0 rw pacija chrome 1549 5* pipe fffffe00833669e0 <-> fffffe0083366888 0 rw pacija chrome 1549 6* pipe fffffe00066e7b60 <-> fffffe00066e7cb8 0 rw pacija chrome 1549 7* pipe fffffe00066e7cb8 <-> fffffe00066e7b60 0 rw pacija chrome 1549 8* pipe fffffe0006567b60 <-> fffffe0006567cb8 0 rw pacija chrome 1549 9* pipe fffffe0006567cb8 <-> fffffe0006567b60 0 rw pacija chrome 1549 10 / 1311571 -r--r--r-- 4237426 r pacija chrome 1549 11 / 1311572 -r--r--r-- 880672 r pacija chrome 1549 12 / 2814041 -r--r--r-- 165391 r pacija chrome 1549 13 / 1311574 -r--r--r-- 5473882 r pacija chrome 1549 14 /dev 25 crw-rw-rw- random r pacija chrome 1549 16* pipe fffffe008396a888 <-> fffffe008396a9e0 0 rw pacija chrome 1549 17* pipe fffffe008396a9e0 <-> fffffe008396a888 0 rw pacija chrome 1549 19* pipe fffffe0083366b60 <-> fffffe0083366cb8 0 rw pacija chrome 1549 20* pipe fffffe0083366cb8 <-> fffffe0083366b60 0 rw pacija chrome 1549 22* pipe fffffe008327f000 <-> fffffe008327f158 0 rw pacija chrome 1549 23* pipe fffffe008327f158 <-> fffffe008327f000 0 rw pacija chrome 1549 24 / 5059383 -rw------- 9216 rw pacija chrome 1549 25 / 5059385 -rw------- 11264 rw pacija chrome 1549 27 / 2 drwxr-xr-x 1024 r pacija chrome 1549 28 / 3049728 drwxr-xr-x 512 r pacija chrome 1549 29 / 3049736 drwxr-xr-x 512 r pacija chrome 1549 30 / 3392715 drwxr-xr-x 2048 r pacija chrome 1549 32 / 2 drwxr-xr-x 1024 r pacija chrome 1549 33 / 3049728 drwxr-xr-x 512 r pacija chrome 1549 34 / 3049736 drwxr-xr-x 512 r pacija chrome 1549 35 / 3392715 drwxr-xr-x 2048 r pacija chrome 1549 37 / 2 drwxr-xr-x 1024 r pacija chrome 1549 38 / 3049728 drwxr-xr-x 512 r pacija chrome 1549 39 / 3049736 drwxr-xr-x 512 r pacija chrome 1549 40 / 3775462 drwxr-xr-x 4096 r pacija chrome 1549 41 / 1311566 drwxr-xr-x 512 r pacija chrome 1549 43 / 2 drwxr-xr-x 1024 r pacija chrome 1549 44 / 3131768 drwxr-xr-x 512 r pacija chrome 1549 45 / 3131772 drwxr-xr-x 6656 r pacija chrome 1549 47 / 2 drwxr-xr-x 1024 r pacija chrome 1549 48 / 3049728 drwxr-xr-x 512 r pacija chrome 1549 49 / 3049732 drwxr-xr-x 12800 r pacija chrome 1549 51 / 2 drwxr-xr-x 1024 r pacija chrome 1549 52 / 3049728 drwxr-xr-x 512 r pacija chrome 1549 53 / 3049732 drwxr-xr-x 12800 r pacija chrome 1549 55 / 2 drwxr-xr-x 1024 r pacija chrome 1549 56 / 3049728 drwxr-xr-x 512 r pacija chrome 1549 57 / 3049732 drwxr-xr-x 12800 r pacija chrome 1549 59 / 2 drwxr-xr-x 1024 r pacija chrome 1549 60 / 3049728 drwxr-xr-x 512 r pacija chrome 1549 61 / 3049732 drwxr-xr-x 12800 r pacija chrome 1549 63 / 2 drwxr-xr-x 1024 r pacija chrome 1549 64 / 3049728 drwxr-xr-x 512 r pacija chrome 1549 66 / 2 drwxr-xr-x 1024 r pacija chrome 1549 67 / 3049728 drwxr-xr-x 512 r pacija chrome 1549 69 / 2 drwxr-xr-x 1024 r pacija chrome 1549 70 / 3049728 drwxr-xr-x 512 r pacija chrome 1549 72 / 2 drwxr-xr-x 1024 r pacija chrome 1549 73 / 3049728 drwxr-xr-x 512 r pacija chrome 1549 74 / 5778443 -rw-r--r-- 51 w pacija chrome 1549 75* local stream fffffe0083f58a50 pacija chrome 1549 76 / 5778444 -rw------- 0 rw pacija chrome 1549 77 / 5778447 -rw-r--r-- 0 w pacija chrome 1549 78 / 5778448 -rw-r--r-- 50 w pacija chrome 1549 79 / 5059409 -rw-r--r-- 1172480 rw pacija chrome 1549 80 / 5218887 -rw------- 929792 rw pacija chrome 1549 81 / 5059398 -rw-r--r-- 360448 rw pacija chrome 1549 82 / 5218892 -rw------- 16621568 rw pacija chrome 1549 83 / 5217094 -rw------- 6561792 rw pacija chrome 1549 84 / 5056600 -rw-r--r-- 454656 rw pacija chrome 1549 85 / 5218894 -rw------- 30416896 rw pacija chrome 1549 86 - - ?(tmpfs) - pacija chrome 1549 87* local stream fffffe0083ea8d20 <-> fffffe0083ea8c30 pacija chrome 1549 88 / 5059405 -rw-r--r-- 147456 rw pacija chrome 1549 89 / 1284193 -rw------- 16400 rw pacija chrome 1549 91 / 2 drwxr-xr-x 1024 r pacija chrome 1549 92 / 3131768 drwxr-xr-x 512 r pacija chrome 1549 93 / 3131772 drwxr-xr-x 6656 r pacija chrome 1549 94 / 3151955 drwxr-xr-x 1024 r pacija chrome 1549 95 / 5059381 drwx------ 1024 r pacija chrome 1549 96 / 5059390 drwx------ 1536 r pacija chrome 1549 97 / 5059399 drwx------ 512 r pacija chrome 1549 98 / 5059407 -rw-r--r-- 0 r pacija chrome 1549 99 / 5056635 -rw------- 260309 w pacija chrome 1549 100 / 1284410 -rw------- 12300 rw pacija chrome 1549 101 / 5059416 -rw-r--r-- 131072 rw pacija chrome 1549 102 / 5059408 -rw-r--r-- 1531904 rw pacija chrome 1549 103* local stream fffffe00835d0a50 <-> fffffe0006948b40 pacija chrome 1549 104 / 5059412 -rw-r--r-- 1064960 rw pacija chrome 1549 105 - - ?(tmpfs) - pacija chrome 1549 106 / 5056133 -rw-r--r-- 57344 rw pacija chrome 1549 107* local stream fffffe0083ada690 <-> fffffe0083ada5a0 pacija chrome 1549 108 / 5059417 -rw-r--r-- 935936 rw pacija chrome 1549 109 / 5218885 -rw------- 262512 rw pacija chrome 1549 110 / 5218897 -rw------- 50339840 rw pacija chrome 1549 111 / 5056579 -rw-r--r-- 12288 rw pacija chrome 1549 112 / 5059426 -rw-r--r-- 25600 rw pacija chrome 1549 113 / 5056668 -rw------- 9437 w pacija chrome 1549 114* local stream fffffe0083ad92d0 <-> fffffe0083ad91e0 pacija chrome 1549 115 / 5059386 -rw-r--r-- 16384 rw pacija chrome 1549 117 / 5778451 -rw-r--r-- 51 w pacija chrome 1549 118 / 5778446 -rw------- 0 rw pacija chrome 1549 119* local stream fffffe000670a3c0 <-> fffffe0083f58d20 pacija chrome 1549 120 / 5778454 -rw-r--r-- 0 w pacija chrome 1549 121 / 5778455 -rw-r--r-- 50 w pacija chrome 1549 122 / 5059410 -rw-r--r-- 16384 rw pacija chrome 1549 123* local stream fffffe0083ada2d0 <-> fffffe0083ada1e0 pacija chrome 1549 124 / 5056409 -rw-r--r-- 12288 rw pacija chrome 1549 125* local stream fffffe00835d0d20 <-> fffffe00835d0c30 pacija chrome 1549 126 / 5059406 -rw-r--r-- 16384 rw pacija chrome 1549 127* local stream fffffe0083e0c000 <-> fffffe0083e0c0f0 pacija chrome 1549 128 / 5056602 -rw-r--r-- 512 rw pacija chrome 1549 129* local stream fffffe0006a59780 <-> fffffe00835d0e10 pacija chrome 1549 130 / 1284369 -rw------- 4104 rw pacija chrome 1549 131* local stream fffffe0083e04960 <-> fffffe0083e04a50 pacija chrome 1549 134* internet stream tcp fffffe00aa1e7000 pacija chrome 1549 135 / 5059413 -rw-r--r-- 16384 rw pacija chrome 1549 136 / 5056452 -rw-r--r-- 3072 rw pacija chrome 1549 137 / 5059460 -rw-r--r-- 6144 rw pacija chrome 1549 138* local stream fffffe00835d05a0 <-> fffffe00834d32d0 pacija chrome 1549 140* local stream fffffe0083e04c30 <-> fffffe0006924780 pacija chrome 1549 141* local stream fffffe0083e0c690 <-> fffffe0083e0cc30 pacija chrome 1549 142* local stream fffffe0083ea81e0 <-> fffffe0083bcaa50 pacija chrome 1549 144 / 5056410 -rw-r--r-- 19152896 rw pacija chrome 1549 145* local stream fffffe0083ada4b0 <-> fffffe0083ada3c0 pacija chrome 1549 146 / 5056722 -rw-r--r-- 16384 rw pacija chrome 1549 147 / 5056662 -rw-r--r-- 3072 rw pacija chrome 1549 151* local stream fffffe00069730f0 <-> fffffe0083bcab40 pacija chrome 1549 160 / 5056513 -rw-r--r-- 291 w pacija chrome 1549 161 / 5059489 -rw------- 0 rw pacija chrome 1549 167 / 5056723 -rw-r--r-- 541987 w pacija chrome 1549 168 / 5056679 -rw-r--r-- 53140 r pacija chrome 1549 169 / 5056730 -rw-r--r-- 211 w pacija chrome 1549 170 / 5056577 -rw-r--r-- 53373 r pacija chrome 1549 171 / 5056637 -rw-r--r-- 53046 r pacija gvfsd-metadata 1507 root / 2 drwxr-xr-x 1024 r pacija gvfsd-metadata 1507 wd / 2 drwxr-xr-x 1024 r pacija gvfsd-metadata 1507 text / 3781315 -r-xr-xr-x 50424 r pacija gvfsd-metadata 1507 0 /dev 19 crw-rw-rw- null rw pacija gvfsd-metadata 1507 1 /dev 19 crw-rw-rw- null rw pacija gvfsd-metadata 1507 2 /dev 19 crw-rw-rw- null rw pacija gvfsd-metadata 1507 3* pipe fffffe00066e6000 <-> fffffe00066e6158 0 rw pacija gvfsd-metadata 1507 4* pipe fffffe00066e6158 <-> fffffe00066e6000 0 rw pacija gvfsd-metadata 1507 5 / 2970888 drwxr-xr-x 512 r pacija gvfsd-metadata 1507 6 / 2752538 drwxr-xr-x 512 r pacija gvfsd-metadata 1507 7 / 3936387 drwxr-xr-x 1536 r pacija gvfsd-metadata 1507 8 / 3936387 drwxr-xr-x 1536 r pacija gvfsd-metadata 1507 9* local stream fffffe0083bcac30 <-> fffffe0083f59690 pacija gvfsd-metadata 1507 10 / 3130170 -rw------- 11588 r pacija gvfsd-metadata 1507 11 / 3130441 -rw-r--r-- 32768 rw pacija gvfsd-trash 1501 root / 2 drwxr-xr-x 1024 r pacija gvfsd-trash 1501 wd / 2 drwxr-xr-x 1024 r pacija gvfsd-trash 1501 text / 3781320 -r-xr-xr-x 158544 r pacija gvfsd-trash 1501 0 /dev 19 crw-rw-rw- null r pacija gvfsd-trash 1501 1 /dev 19 crw-rw-rw- null rw pacija gvfsd-trash 1501 2 /dev 19 crw-rw-rw- null rw pacija gvfsd-trash 1501 3* local stream fffffe0083e05960 <-> fffffe0083e05870 pacija gvfsd-trash 1501 4* pipe fffffe0006447b60 <-> fffffe0006447cb8 0 rw pacija gvfsd-trash 1501 5* pipe fffffe0006447cb8 <-> fffffe0006447b60 0 rw pacija gvfsd-trash 1501 6* local stream fffffe00069484b0 <-> fffffe000670ad20 pacija gvfsd-trash 1501 8* local stream fffffe000670ae10 <-> fffffe0083e0d780 pacija gvfsd-trash 1501 9* local stream fffffe0083e0d780 <-> fffffe000670ae10 pacija gvfsd-trash 1501 10* local stream fffffe0083e0d690 <-> fffffe0083e0d5a0 pacija gvfsd-trash 1501 11 / 2408050 -rw-r--r-- 375 r pacija gvfsd-trash 1501 12 / 3151962 drwx------ 512 r pacija gvfsd-trash 1501 13* local stream fffffe008364f1e0 <-> fffffe008364f2d0 pacija gvfsd-trash 1501 14* local stream fffffe008364f3c0 <-> fffffe008364f4b0 pacija gvfsd-trash 1501 15 / 4107675 drwx------ 512 r pacija gvfsd-trash 1501 16 / 4107677 drwx------ 1536 r pacija gvfsd-trash 1501 17* local stream fffffe0006a5a780 <-> fffffe0006a5a870 pacija gvfsd-trash 1501 19* local stream fffffe0006a5a5a0 <-> fffffe0006a5a690 pacija wrapper 1498 root / 2 drwxr-xr-x 1024 r pacija wrapper 1498 wd / 3131772 drwxr-xr-x 6656 r pacija wrapper 1498 text / 4013148 -r-xr-xr-x 26040 r pacija wrapper 1498 ctty /dev 47 crw------- ttyv1 rw pacija wrapper 1498 0 /dev 19 crw-rw-rw- null r pacija wrapper 1498 1 /dev 47 crw------- ttyv1 rw pacija wrapper 1498 2 /dev 47 crw------- ttyv1 rw pacija wrapper 1498 3* local stream fffffe0006948690 <-> fffffe0006a59b40 pacija wrapper 1498 4* pipe fffffe0006683b60 <-> fffffe0006683cb8 0 rw pacija wrapper 1498 5* pipe fffffe0006683cb8 <-> fffffe0006683b60 0 rw pacija wrapper 1498 6* local stream fffffe0006973b40 <-> fffffe00069241e0 pacija wrapper 1498 7* local stream fffffe00069235a0 <-> fffffe0006972690 pacija gconfd-2 1492 root / 2 drwxr-xr-x 1024 r pacija gconfd-2 1492 wd / 2 drwxr-xr-x 1024 r pacija gconfd-2 1492 text / 3772679 -r-xr-xr-x 66616 r pacija gconfd-2 1492 0 /dev 19 crw-rw-rw- null rw pacija gconfd-2 1492 1 /dev 19 crw-rw-rw- null rw pacija gconfd-2 1492 2 /dev 19 crw-rw-rw- null rw pacija gconfd-2 1492 3 /dev 19 crw-rw-rw- null rw pacija gconfd-2 1492 4* pipe fffffe0006530b60 <-> fffffe0006530cb8 10 rw pacija gconfd-2 1492 5 / 2970888 drwxr-xr-x 512 r pacija gconfd-2 1492 6 / 2752538 drwxr-xr-x 512 r pacija gconfd-2 1492 7 / 3936387 drwxr-xr-x 1536 r pacija gconfd-2 1492 8 / 3936387 drwxr-xr-x 1536 r pacija gconfd-2 1492 9* pipe fffffe0006530cb8 <-> fffffe0006530b60 0 rw pacija gconfd-2 1492 10* pipe fffffe000646a888 <-> fffffe000646a9e0 0 rw pacija gconfd-2 1492 11* pipe fffffe000646a9e0 <-> fffffe000646a888 0 rw pacija gconfd-2 1492 12* pipe fffffe0006534b60 <-> fffffe0006534cb8 0 rw pacija gconfd-2 1492 13* pipe fffffe0006534cb8 <-> fffffe0006534b60 0 rw pacija gconfd-2 1492 14* local stream fffffe00069731e0 pacija gconfd-2 1492 15* local stream fffffe00069732d0 <-> fffffe00069733c0 pacija gconfd-2 1492 16* local stream fffffe0006a594b0 <-> fffffe000670a5a0 pacija gconfd-2 1492 17* local stream fffffe0083e0d960 <-> fffffe0083e0da50 pacija gconfd-2 1492 18* local stream fffffe0083ad9d20 <-> fffffe000670b000 pacija gconfd-2 1492 19* local stream fffffe0006973d20 <-> fffffe0006972870 pacija gconfd-2 1492 20* local stream fffffe0083bca5a0 <-> fffffe0083bca4b0 pacija xfce4-orageclock-p 1486 root / 2 drwxr-xr-x 1024 r pacija xfce4-orageclock-p 1486 wd / 3131772 drwxr-xr-x 6656 r pacija xfce4-orageclock-p 1486 text / 4183609 -r-xr-xr-x 85648 r pacija xfce4-orageclock-p 1486 ctty /dev 47 crw------- ttyv1 rw pacija xfce4-orageclock-p 1486 0 /dev 19 crw-rw-rw- null r pacija xfce4-orageclock-p 1486 1 /dev 47 crw------- ttyv1 rw pacija xfce4-orageclock-p 1486 2 /dev 47 crw------- ttyv1 rw pacija xfce4-orageclock-p 1486 3* local stream fffffe00835d00f0 <-> fffffe00835d0000 pacija xfce4-orageclock-p 1486 4* pipe fffffe0083365888 <-> fffffe00833659e0 0 rw pacija xfce4-orageclock-p 1486 5* pipe fffffe00833659e0 <-> fffffe0083365888 0 rw pacija wrapper 1485 root / 2 drwxr-xr-x 1024 r pacija wrapper 1485 wd / 3131772 drwxr-xr-x 6656 r pacija wrapper 1485 text / 4013148 -r-xr-xr-x 26040 r pacija wrapper 1485 ctty /dev 47 crw------- ttyv1 rw pacija wrapper 1485 0 /dev 19 crw-rw-rw- null r pacija wrapper 1485 1 /dev 47 crw------- ttyv1 rw pacija wrapper 1485 2 /dev 47 crw------- ttyv1 rw pacija wrapper 1485 3* local stream fffffe0006a5a1e0 <-> fffffe00069233c0 pacija wrapper 1485 4* pipe fffffe0006535888 <-> fffffe00065359e0 0 rw pacija wrapper 1485 5* pipe fffffe00065359e0 <-> fffffe0006535888 0 rw pacija wrapper 1485 6* local stream fffffe00069480f0 <-> fffffe00069482d0 pacija wrapper 1484 root / 2 drwxr-xr-x 1024 r pacija wrapper 1484 wd / 3131772 drwxr-xr-x 6656 r pacija wrapper 1484 text / 4013148 -r-xr-xr-x 26040 r pacija wrapper 1484 ctty /dev 47 crw------- ttyv1 rw pacija wrapper 1484 0 /dev 19 crw-rw-rw- null r pacija wrapper 1484 1 /dev 47 crw------- ttyv1 rw pacija wrapper 1484 2 /dev 47 crw------- ttyv1 rw pacija wrapper 1484 3* local stream fffffe0006924000 <-> fffffe00069230f0 pacija wrapper 1484 4* pipe fffffe00833655b0 <-> fffffe0083365708 0 rw pacija wrapper 1484 5* pipe fffffe0083365708 <-> fffffe00833655b0 0 rw pacija wrapper 1484 6* local stream fffffe008364fe10 <-> fffffe008364fd20 pacija wrapper 1484 7* internet stream tcp fffffe0020dccb70 pacija gvfs-gphoto2-volum 1482 root / 2 drwxr-xr-x 1024 r pacija gvfs-gphoto2-volum 1482 wd / 2 drwxr-xr-x 1024 r pacija gvfs-gphoto2-volum 1482 text / 3781318 -r-xr-xr-x 67704 r pacija gvfs-gphoto2-volum 1482 0 /dev 19 crw-rw-rw- null rw pacija gvfs-gphoto2-volum 1482 1 /dev 19 crw-rw-rw- null rw pacija gvfs-gphoto2-volum 1482 2 /dev 19 crw-rw-rw- null rw pacija gvfs-gphoto2-volum 1482 3* pipe fffffe0006429888 <-> fffffe00064299e0 0 rw pacija gvfs-gphoto2-volum 1482 4* pipe fffffe00064299e0 <-> fffffe0006429888 0 rw pacija gvfs-gphoto2-volum 1482 5 / 2970888 drwxr-xr-x 512 r pacija gvfs-gphoto2-volum 1482 6 / 2752538 drwxr-xr-x 512 r pacija gvfs-gphoto2-volum 1482 7 / 3936387 drwxr-xr-x 1536 r pacija gvfs-gphoto2-volum 1482 8 / 3936387 drwxr-xr-x 1536 r pacija gvfs-gphoto2-volum 1482 9* local stream fffffe0006923780 <-> fffffe0006923690 pacija gvfs-gphoto2-volum 1482 10* local stream fffffe00834d34b0 <-> fffffe00834d33c0 pacija gvfs-hal-volume-mo 1479 root / 2 drwxr-xr-x 1024 r pacija gvfs-hal-volume-mo 1479 wd / 2 drwxr-xr-x 1024 r pacija gvfs-hal-volume-mo 1479 text / 3781447 -r-xr-xr-x 100096 r pacija gvfs-hal-volume-mo 1479 0 /dev 19 crw-rw-rw- null rw pacija gvfs-hal-volume-mo 1479 1 /dev 19 crw-rw-rw- null rw pacija gvfs-hal-volume-mo 1479 2 /dev 19 crw-rw-rw- null rw pacija gvfs-hal-volume-mo 1479 3* pipe fffffe008327e888 <-> fffffe008327e9e0 0 rw pacija gvfs-hal-volume-mo 1479 4* pipe fffffe008327e9e0 <-> fffffe008327e888 0 rw pacija gvfs-hal-volume-mo 1479 5 / 2970888 drwxr-xr-x 512 r pacija gvfs-hal-volume-mo 1479 6 / 2752538 drwxr-xr-x 512 r pacija gvfs-hal-volume-mo 1479 7 / 3936387 drwxr-xr-x 1536 r pacija gvfs-hal-volume-mo 1479 8 / 3936387 drwxr-xr-x 1536 r pacija gvfs-hal-volume-mo 1479 9* local stream fffffe0006a5a2d0 <-> fffffe00834d3870 pacija gvfs-hal-volume-mo 1479 10* local stream fffffe0006973780 <-> fffffe0006711780 pacija gvfs-hal-volume-mo 1479 12* local stream fffffe0006923960 <-> fffffe0006923870 pacija gvfs-hal-volume-mo 1479 13* local stream fffffe0006923870 <-> fffffe0006923960 pacija gvfs-hal-volume-mo 1479 14 / 2408050 -rw-r--r-- 375 r pacija gvfs-hal-volume-mo 1479 15* local stream fffffe0006973960 <-> fffffe0006a593c0 pacija gvfs-hal-volume-mo 1479 16* pipe fffffe0006513888 <-> fffffe00065139e0 0 rw pacija gvfs-hal-volume-mo 1479 17* pipe fffffe00065139e0 <-> fffffe0006513888 0 rw root upowerd 1475 root / 2 drwxr-xr-x 1024 r root upowerd 1475 wd / 2 drwxr-xr-x 1024 r root upowerd 1475 text / 3780220 -r-xr-xr-x 108600 r root upowerd 1475 0 /dev 19 crw-rw-rw- null rw root upowerd 1475 1 /dev 19 crw-rw-rw- null rw root upowerd 1475 2 /dev 19 crw-rw-rw- null rw root upowerd 1475 3* local stream fffffe0006973a50 <-> fffffe0006973c30 root upowerd 1475 4* pipe fffffe0006513000 <-> fffffe0006513158 0 rw root upowerd 1475 5 / 3633759 drwxr-xr-x 512 r root upowerd 1475 6 / 4739228 drwxr-xr-x 512 r root upowerd 1475 7 / 3936388 drwxr-xr-x 512 r root upowerd 1475 8* pipe fffffe0006513158 <-> fffffe0006513000 0 rw root upowerd 1475 9* local stream fffffe0006973e10 <-> fffffe0006972a50 root upowerd 1475 10* pipe fffffe00065342d8 <-> fffffe0006534430 0 rw root upowerd 1475 11* pipe fffffe0006534430 <-> fffffe00065342d8 0 rw root upowerd 1475 12* local stream fffffe00834d3690 <-> fffffe00834d35a0 root upowerd 1475 14* pipe fffffe008310d2d8 <-> fffffe008310d430 0 rw root upowerd 1475 15* pipe fffffe008310d430 <-> fffffe008310d2d8 0 rw pacija gvfsd 1473 root / 2 drwxr-xr-x 1024 r pacija gvfsd 1473 wd / 2 drwxr-xr-x 1024 r pacija gvfsd 1473 text / 3781316 -r-xr-xr-x 143640 r pacija gvfsd 1473 0 /dev 19 crw-rw-rw- null rw pacija gvfsd 1473 1 /dev 19 crw-rw-rw- null rw pacija gvfsd 1473 2 /dev 19 crw-rw-rw- null rw pacija gvfsd 1473 3* local stream fffffe00835d02d0 <-> fffffe00835d01e0 pacija gvfsd 1473 4* pipe fffffe00833662d8 <-> fffffe0083366430 0 rw pacija gvfsd 1473 5 / 2970888 drwxr-xr-x 512 r pacija gvfsd 1473 6 / 2752538 drwxr-xr-x 512 r pacija gvfsd 1473 7 / 3936387 drwxr-xr-x 1536 r pacija gvfsd 1473 8 / 3936387 drwxr-xr-x 1536 r pacija gvfsd 1473 9* pipe fffffe0083366430 <-> fffffe00833662d8 0 rw pacija gvfsd 1473 10* pipe fffffe00831225b0 <-> fffffe0083122708 0 rw pacija gvfsd 1473 11* pipe fffffe0083122708 <-> fffffe00831225b0 0 rw pacija xfce4-power-manage 1469 root / 2 drwxr-xr-x 1024 r pacija xfce4-power-manage 1469 wd / 2 drwxr-xr-x 1024 r pacija xfce4-power-manage 1469 text / 3290687 -r-xr-xr-x 151288 r pacija xfce4-power-manage 1469 0 /dev 19 crw-rw-rw- null rw pacija xfce4-power-manage 1469 1 /dev 19 crw-rw-rw- null rw pacija xfce4-power-manage 1469 2 /dev 19 crw-rw-rw- null rw pacija xfce4-power-manage 1469 3* local stream fffffe00834d3a50 <-> fffffe00834d3960 pacija xfce4-power-manage 1469 4* pipe fffffe000646ab60 <-> fffffe000646acb8 0 rw pacija xfce4-power-manage 1469 5* pipe fffffe000646acb8 <-> fffffe000646ab60 0 rw pacija xfce4-power-manage 1469 6* local stream fffffe0006972b40 <-> fffffe0006972d20 pacija xfce4-power-manage 1469 7* local stream fffffe0006948000 <-> fffffe00069481e0 pacija xfce4-power-manage 1469 8* pipe fffffe000668d000 <-> fffffe000668d158 0 rw pacija xfce4-power-manage 1469 9* pipe fffffe000668d158 <-> fffffe000668d000 0 rw pacija xfce4-power-manage 1469 10* local stream fffffe000670a0f0 <-> fffffe000670a000 pacija xfce4-power-manage 1469 11* local stream fffffe0006711690 <-> fffffe0006a59690 pacija xfce4-power-manage 1469 12* pipe fffffe0083298000 <-> fffffe0083298158 0 rw pacija xfce4-power-manage 1469 13* pipe fffffe0083298158 <-> fffffe0083298000 0 rw pacija xfce4-power-manage 1469 14* pipe fffffe00839695b0 <-> fffffe0083969708 0 rw pacija xfce4-power-manage 1469 15* pipe fffffe0083969708 <-> fffffe00839695b0 0 rw pacija xfce4-power-manage 1469 16* local stream fffffe0083ad9870 <-> fffffe0083ad9780 pacija nautilus 1465 root / 2 drwxr-xr-x 1024 r pacija nautilus 1465 wd / 3131772 drwxr-xr-x 6656 r pacija nautilus 1465 text / 3295193 -r-xr-xr-x 1830120 r pacija nautilus 1465 ctty /dev 47 crw------- ttyv1 rw pacija nautilus 1465 0 /dev 19 crw-rw-rw- null r pacija nautilus 1465 1 /dev 47 crw------- ttyv1 rw pacija nautilus 1465 2 /dev 47 crw------- ttyv1 rw pacija nautilus 1465 3* local stream fffffe008364fc30 <-> fffffe008364fb40 pacija nautilus 1465 4* pipe fffffe00833652d8 <-> fffffe0083365430 0 rw pacija nautilus 1465 5* pipe fffffe0083365430 <-> fffffe00833652d8 0 rw pacija nautilus 1465 6* local stream fffffe008364fa50 <-> fffffe008364f960 pacija nautilus 1465 7* pipe fffffe0083365000 <-> fffffe0083365158 0 rw pacija nautilus 1465 8* pipe fffffe0083365158 <-> fffffe0083365000 0 rw pacija nautilus 1465 9* pipe fffffe0083969b60 <-> fffffe0083969cb8 0 rw pacija nautilus 1465 10* pipe fffffe008327e2d8 <-> fffffe008327e430 0 rw pacija nautilus 1465 11* pipe fffffe008327e430 <-> fffffe008327e2d8 0 rw pacija nautilus 1465 12* pipe fffffe0083969cb8 <-> fffffe0083969b60 0 rw pacija nautilus 1465 13* pipe fffffe0083969888 <-> fffffe00839699e0 0 rw pacija nautilus 1465 14* pipe fffffe00839699e0 <-> fffffe0083969888 0 rw pacija nautilus 1465 15* local stream fffffe000670b000 <-> fffffe0083ad9d20 pacija nautilus 1465 16* local stream fffffe008364f780 pacija nautilus 1465 17* local stream fffffe0006972870 <-> fffffe0006973d20 pacija nautilus 1465 18* local stream fffffe00834d30f0 <-> fffffe00834d3000 pacija nautilus 1465 19* local stream fffffe0083ad9c30 <-> fffffe0083ad9b40 pacija nautilus 1465 21* local stream fffffe0083ad9a50 <-> fffffe0083ad9960 pacija nautilus 1465 22* local stream fffffe0083ad9960 <-> fffffe0083ad9a50 pacija nautilus 1465 23* local stream fffffe0006a5ae10 <-> fffffe0006a5ad20 pacija nautilus 1465 24* local stream fffffe008364f4b0 <-> fffffe008364f3c0 pacija nautilus 1465 25* local stream fffffe008364f2d0 <-> fffffe008364f1e0 pacija nautilus 1465 26* pipe fffffe00839692d8 <-> fffffe0083969430 0 rw pacija nautilus 1465 27* local stream fffffe0083e0d4b0 <-> fffffe0083e0d3c0 pacija nautilus 1465 28 / 3137084 -rw-r--r-- 66 r pacija nautilus 1465 29* local stream fffffe008364f0f0 <-> fffffe008364f000 pacija nautilus 1465 30* pipe fffffe0083969430 <-> fffffe00839692d8 0 rw pacija nautilus 1465 31 / 3151971 drwxr-xr-x 1536 r pacija nautilus 1465 32* local stream fffffe0006a5a870 <-> fffffe0006a5a780 pacija nautilus 1465 33* local stream fffffe0006a5a690 <-> fffffe0006a5a5a0 pacija nautilus 1465 34 / 2408050 -rw-r--r-- 375 r pacija nautilus 1465 35 / 3152044 drwxr-xr-x 512 r pacija nautilus 1465 37 / 3131772 drwxr-xr-x 6656 r pacija nautilus 1465 38* pipe fffffe0083969000 <-> fffffe0083969158 0 rw pacija nautilus 1465 39* pipe fffffe0083969158 <-> fffffe0083969000 0 rw pacija nautilus 1465 40 / 3131853 -rw------- 11588 r pacija nautilus 1465 41 / 3132129 -rw-r--r-- 32768 r pacija nautilus 1465 42* local stream fffffe0083e0d2d0 <-> fffffe0083e0d1e0 pacija xfsettingsd 1463 root / 2 drwxr-xr-x 1024 r pacija xfsettingsd 1463 wd / 3131772 drwxr-xr-x 6656 r pacija xfsettingsd 1463 text / 3292704 -r-xr-xr-x 88160 r pacija xfsettingsd 1463 0 /dev 19 crw-rw-rw- null r pacija xfsettingsd 1463 1 /dev 47 crw------- ttyv1 rw pacija xfsettingsd 1463 2 /dev 47 crw------- ttyv1 rw pacija xfsettingsd 1463 3* local stream fffffe0006927960 <-> fffffe0006927a50 pacija xfsettingsd 1463 4* pipe fffffe00066e72d8 <-> fffffe00066e7430 0 rw pacija xfsettingsd 1463 5* pipe fffffe00066e7430 <-> fffffe00066e72d8 0 rw pacija xfsettingsd 1463 6* local stream fffffe0006927b40 <-> fffffe0006927c30 pacija xfsettingsd 1463 7* local stream fffffe00069271e0 <-> fffffe00834d3b40 pacija xfsettingsd 1463 9* pipe fffffe00833665b0 <-> fffffe0083366708 0 rw pacija xfsettingsd 1463 10* pipe fffffe0083366708 <-> fffffe00833665b0 0 rw pacija xfsettingsd 1463 11* local stream fffffe00835d04b0 <-> fffffe00835d03c0 pacija xfsettingsd 1463 13* local stream fffffe00069483c0 <-> fffffe0006a590f0 pacija xfsettingsd 1463 14* local stream fffffe0006a590f0 <-> fffffe00069483c0 pacija xfsettingsd 1463 15* local stream fffffe00069273c0 <-> fffffe000670a1e0 pacija xfsettingsd 1463 16 / 3370992 -r--r--r-- 5523 r pacija xfsettingsd 1463 17 / 3392754 drwxr-xr-x 512 r pacija xfsettingsd 1463 18 / 3370793 -r--r--r-- 1952 r pacija xfsettingsd 1463 19 / 3370951 -r--r--r-- 1259 r pacija xfsettingsd 1463 20 / 3370954 -r--r--r-- 5354 r pacija xfsettingsd 1463 21 / 3370953 -r--r--r-- 1198 r pacija xfsettingsd 1463 22 / 3370955 -r--r--r-- 5182 r pacija xfsettingsd 1463 23 / 3370756 -r--r--r-- 389 r pacija xfsettingsd 1463 24 / 3370956 -r--r--r-- 3948 r pacija xfsettingsd 1463 25 / 3370957 -r--r--r-- 545 r pacija xfsettingsd 1463 26 / 3370958 -r--r--r-- 673 r pacija xfsettingsd 1463 27 / 3370959 -r--r--r-- 189 r pacija xfsettingsd 1463 28 / 3370960 -r--r--r-- 1701 r pacija xfsettingsd 1463 29 / 3370961 -r--r--r-- 10118 r pacija xfsettingsd 1463 30 / 3370964 -r--r--r-- 7959 r pacija xfsettingsd 1463 31 / 3370965 -r--r--r-- 672 r pacija xfsettingsd 1463 32 / 3370974 -r--r--r-- 422 r pacija xfsettingsd 1463 33 / 3370975 -r--r--r-- 1691 r pacija xfsettingsd 1463 34 / 2809116 drwxr-xr-x 512 r pacija xfsettingsd 1463 35 / 3775347 drwxr-xr-x 512 r pacija xfsettingsd 1463 36 / 2809117 drwxr-xr-x 512 r pacija xfsettingsd 1463 37 / 3853062 drwxr-xr-x 65536 r pacija xfsettingsd 1463 38 / 3853085 drwxr-xr-x 65536 r pacija xfsettingsd 1463 39 / 2572362 drwxr-xr-x 512 r pacija xfsettingsd 1463 40 / 2982601 drwxr-xr-x 512 r pacija xfsettingsd 1463 41 / 4496116 drwxr-xr-x 1024 r pacija xfsettingsd 1463 42 / 2651361 drwxr-xr-x 512 r pacija xfsettingsd 1463 43 / 3854699 drwxr-xr-x 1024 r pacija xfsettingsd 1463 44 / 3854684 drwxr-xr-x 512 r pacija xfsettingsd 1463 45 / 3854605 drwxr-xr-x 1536 r pacija xfsettingsd 1463 46 / 2823708 drwxr-xr-x 512 r pacija xfsettingsd 1463 47 / 3853090 drwxr-xr-x 2560 r pacija xfsettingsd 1463 48 / 2981074 drwxr-xr-x 1024 r pacija xfsettingsd 1463 49 / 2981014 drwxr-xr-x 1536 r pacija xfsettingsd 1463 50 / 3775348 drwxr-xr-x 512 r pacija xfsettingsd 1463 51 / 3853108 drwxr-xr-x 12800 r pacija xfsettingsd 1463 52 / 5383444 drwxr-xr-x 6144 r pacija xfsettingsd 1463 53 / 2980888 drwxr-xr-x 512 r pacija xfsettingsd 1463 54 / 2981085 drwxr-xr-x 1024 r pacija xfce4-panel 1462 root / 2 drwxr-xr-x 1024 r pacija xfce4-panel 1462 wd / 3131772 drwxr-xr-x 6656 r pacija xfce4-panel 1462 text / 3291948 -r-xr-xr-x 288632 r pacija xfce4-panel 1462 ctty /dev 47 crw------- ttyv1 rw pacija xfce4-panel 1462 0 /dev 19 crw-rw-rw- null r pacija xfce4-panel 1462 1 /dev 47 crw------- ttyv1 rw pacija xfce4-panel 1462 2 /dev 47 crw------- ttyv1 rw pacija xfce4-panel 1462 3* local stream fffffe0006948d20 <-> fffffe0006972960 pacija xfce4-panel 1462 4* pipe fffffe00066e75b0 <-> fffffe00066e7708 0 rw pacija xfce4-panel 1462 5* pipe fffffe00066e7708 <-> fffffe00066e75b0 0 rw pacija xfce4-panel 1462 6* local stream fffffe000670b690 <-> fffffe000670ba50 pacija xfce4-panel 1462 7* local stream fffffe000670b2d0 <-> fffffe000670b1e0 pacija xfce4-panel 1462 8* pipe fffffe00064475b0 <-> fffffe0006447708 0 rw pacija xfce4-panel 1462 9* pipe fffffe0006447708 <-> fffffe00064475b0 0 rw pacija xfce4-panel 1462 10* local stream fffffe0006a595a0 <-> fffffe00067115a0 pacija xfce4-panel 1462 12* local stream fffffe000670a4b0 <-> fffffe00067113c0 pacija xfce4-panel 1462 13* local stream fffffe00067113c0 <-> fffffe000670a4b0 pacija xfce4-panel 1462 14* local stream fffffe0083ada0f0 <-> fffffe0083ada000 pacija xfce4-panel 1462 15 / 4815360 drwx------ 512 r pacija xfce4-panel 1462 16 / 4175014 drwx------ 512 r pacija xfce4-panel 1462 17 / 4815362 drwx------ 512 r pacija xfce4-panel 1462 18 / 4815364 drwx------ 512 r pacija xfce4-panel 1462 19 / 4815366 drwx------ 512 r pacija xfce4-panel 1462 20 / 4815368 drwx------ 512 r pacija xfce4-panel 1462 21 / 4815370 drwx------ 512 r pacija xfce4-panel 1462 22 / 4815372 drwx------ 512 r pacija xfce4-panel 1462 23 / 4815374 drwx------ 512 r pacija xfce4-panel 1462 24 / 4815376 drwx------ 512 r pacija xfce4-panel 1462 25 / 4815378 drwx------ 512 r pacija xfce4-panel 1462 26 / 4815380 drwx------ 512 r pacija xfce4-panel 1462 27 / 4815382 drwx------ 512 r pacija xfce4-panel 1462 28 / 4012860 -r--r--r-- 4293 r pacija xfce4-panel 1462 29 / 4739316 drwxr-xr-x 512 r pacija xfce4-panel 1462 30 / 3856378 drwxr-xr-x 3584 r pacija xfce4-panel 1462 31 / 3152037 drwx------ 512 r pacija xfce4-panel 1462 32 / 4183431 -r--r--r-- 4106 r pacija xfce4-panel 1462 33 / 4183430 -r--r--r-- 3390 r pacija xfce4-panel 1462 34 / 4183431 -r--r--r-- 4106 r pacija xfce4-panel 1462 35 / 4183419 -r--r--r-- 3916 r pacija xfce4-panel 1462 36 / 4183420 -r--r--r-- 3229 r pacija xfce4-panel 1462 37 / 4183421 -r--r--r-- 2671 r pacija xfce4-panel 1462 38 / 4183422 -r--r--r-- 3654 r pacija xfce4-panel 1462 39 / 4183423 -r--r--r-- 3903 r pacija xfce4-panel 1462 40 / 4183425 -r--r--r-- 3866 r pacija xfce4-panel 1462 41 / 4183426 -r--r--r-- 3191 r pacija xfce4-panel 1462 42 / 4183427 -r--r--r-- 3250 r pacija xfce4-panel 1462 43 / 4183432 -r--r--r-- 2959 r pacija xfce4-panel 1462 44 / 4183428 -r--r--r-- 3797 r pacija xfwm4 1460 root / 2 drwxr-xr-x 1024 r pacija xfwm4 1460 wd / 3131772 drwxr-xr-x 6656 r pacija xfwm4 1460 text / 3292904 -r-xr-xr-x 330952 r pacija xfwm4 1460 ctty /dev 47 crw------- ttyv1 rw pacija xfwm4 1460 0 /dev 19 crw-rw-rw- null r pacija xfwm4 1460 1 /dev 47 crw------- ttyv1 rw pacija xfwm4 1460 2 /dev 47 crw------- ttyv1 rw pacija xfwm4 1460 3* local stream fffffe000670a2d0 <-> fffffe0006923e10 pacija xfwm4 1460 4* pipe fffffe00832982d8 <-> fffffe0083298430 0 rw pacija xfwm4 1460 5* pipe fffffe0083298430 <-> fffffe00832982d8 0 rw pacija xfwm4 1460 6* local stream fffffe0006923b40 <-> fffffe0006923a50 pacija xfwm4 1460 7* local stream fffffe0006927780 <-> fffffe0006927870 pacija gpg-agent 1459 root / 2 drwxr-xr-x 1024 r pacija gpg-agent 1459 wd / 2 drwxr-xr-x 1024 r pacija gpg-agent 1459 text / 3295068 -r-xr-xr-x 283672 r pacija gpg-agent 1459 0 /dev 19 crw-rw-rw- null r pacija gpg-agent 1459 1 /dev 19 crw-rw-rw- null w pacija gpg-agent 1459 2 /dev 19 crw-rw-rw- null w pacija gpg-agent 1459 3* pipe fffffe00832985b0 <-> fffffe0083298708 0 rw pacija gpg-agent 1459 4* pipe fffffe0083298708 <-> fffffe00832985b0 0 rw pacija gpg-agent 1459 5* local stream fffffe0006972c30 pacija gpg-agent 1459 6* local stream fffffe00069243c0 pacija xfconfd 1456 root / 2 drwxr-xr-x 1024 r pacija xfconfd 1456 wd / 2 drwxr-xr-x 1024 r pacija xfconfd 1456 text / 2982716 -r-xr-xr-x 71088 r pacija xfconfd 1456 0 /dev 19 crw-rw-rw- null rw pacija xfconfd 1456 1 /dev 19 crw-rw-rw- null rw pacija xfconfd 1456 2 /dev 19 crw-rw-rw- null rw pacija xfconfd 1456 3* pipe fffffe000668d888 <-> fffffe000668d9e0 0 rw pacija xfconfd 1456 4* pipe fffffe000668d9e0 <-> fffffe000668d888 0 rw pacija xfconfd 1456 5 / 2970888 drwxr-xr-x 512 r pacija xfconfd 1456 6 / 2752538 drwxr-xr-x 512 r pacija xfconfd 1456 7 / 3936387 drwxr-xr-x 1536 r pacija xfconfd 1456 8 / 3936387 drwxr-xr-x 1536 r pacija xfconfd 1456 9* pipe fffffe00833672d8 <-> fffffe0083367430 0 rw pacija xfconfd 1456 10* pipe fffffe0083367430 <-> fffffe00833672d8 0 rw pacija xfconfd 1456 11* local stream fffffe0006711000 <-> fffffe00067111e0 pacija dbus-daemon 1454 root / 2 drwxr-xr-x 1024 r pacija dbus-daemon 1454 wd / 2 drwxr-xr-x 1024 r pacija dbus-daemon 1454 text / 3290566 -r-xr-xr-x 382392 r pacija dbus-daemon 1454 0 /dev 19 crw-rw-rw- null rw pacija dbus-daemon 1454 1 /dev 19 crw-rw-rw- null rw pacija dbus-daemon 1454 2 /dev 19 crw-rw-rw- null rw pacija dbus-daemon 1454 3* local stream fffffe0006923c30 pacija dbus-daemon 1454 5 / 2970888 drwxr-xr-x 512 r pacija dbus-daemon 1454 6 / 2752538 drwxr-xr-x 512 r pacija dbus-daemon 1454 7 / 3936387 drwxr-xr-x 1536 r pacija dbus-daemon 1454 8 / 3936387 drwxr-xr-x 1536 r pacija dbus-daemon 1454 9* local stream fffffe00069245a0 <-> fffffe00069735a0 pacija dbus-daemon 1454 10* local stream fffffe00069735a0 <-> fffffe00069245a0 pacija dbus-daemon 1454 11* local stream fffffe0006927e10 <-> fffffe0006972000 pacija dbus-daemon 1454 12* local stream fffffe0006923a50 <-> fffffe0006923b40 pacija dbus-daemon 1454 13* local stream fffffe00067111e0 <-> fffffe0006711000 pacija dbus-daemon 1454 14* local stream fffffe0006927c30 <-> fffffe0006927b40 pacija dbus-daemon 1454 15* local stream fffffe000670ba50 <-> fffffe000670b690 pacija dbus-daemon 1454 16* local stream fffffe0006972d20 <-> fffffe0006972b40 pacija dbus-daemon 1454 17* local stream fffffe0006a59690 <-> fffffe0006711690 pacija dbus-daemon 1454 18* local stream fffffe00835d01e0 <-> fffffe00835d02d0 pacija dbus-daemon 1454 19* local stream fffffe0083ea8c30 <-> fffffe0083ea8d20 pacija dbus-daemon 1454 20* local stream fffffe000670a1e0 <-> fffffe00069273c0 pacija dbus-daemon 1454 21* local stream fffffe00835d03c0 <-> fffffe00835d04b0 pacija dbus-daemon 1454 22* local stream fffffe00069482d0 <-> fffffe00069480f0 pacija dbus-daemon 1454 23* local stream fffffe0006711780 <-> fffffe0006973780 pacija dbus-daemon 1454 24* local stream fffffe00834d33c0 <-> fffffe00834d34b0 pacija dbus-daemon 1454 25* local stream fffffe0006a593c0 <-> fffffe0006973960 pacija dbus-daemon 1454 26* local stream fffffe008364fd20 <-> fffffe008364fe10 pacija dbus-daemon 1454 27* local stream fffffe00067115a0 <-> fffffe0006a595a0 pacija dbus-daemon 1454 28* local stream fffffe0083ada000 <-> fffffe0083ada0f0 pacija dbus-daemon 1454 29* local stream fffffe00834d3000 <-> fffffe00834d30f0 pacija dbus-daemon 1454 30* local stream fffffe00069241e0 <-> fffffe0006973b40 pacija dbus-daemon 1454 31* local stream fffffe00069733c0 <-> fffffe00069732d0 pacija dbus-daemon 1454 32* local stream fffffe0006972690 <-> fffffe00069235a0 pacija dbus-daemon 1454 33* local stream fffffe0083ad9b40 <-> fffffe0083ad9c30 pacija dbus-daemon 1454 34* local stream fffffe0083ad9780 <-> fffffe0083ad9870 pacija dbus-daemon 1454 35* local stream fffffe0083ea9a50 <-> fffffe0083ea9b40 pacija dbus-daemon 1454 36* local stream fffffe0006a5ad20 <-> fffffe0006a5ae10 pacija dbus-daemon 1454 37* local stream fffffe0083e05870 <-> fffffe0083e05960 pacija dbus-daemon 1454 38* local stream fffffe000670ad20 <-> fffffe00069484b0 pacija dbus-daemon 1454 39* local stream fffffe0083e0d5a0 <-> fffffe0083e0d690 pacija dbus-daemon 1454 40* local stream fffffe0083e0d3c0 <-> fffffe0083e0d4b0 pacija dbus-daemon 1454 41* local stream fffffe0083e0d1e0 <-> fffffe0083e0d2d0 pacija dbus-daemon 1454 42* local stream fffffe0083f585a0 <-> fffffe0083f583c0 pacija dbus-daemon 1454 43* local stream fffffe00835d0870 <-> fffffe00835d0960 pacija dbus-daemon 1454 44* local stream fffffe0083e0c3c0 <-> fffffe0083e0c4b0 pacija dbus-daemon 1454 45* local stream fffffe0006a592d0 <-> fffffe0006711870 pacija dbus-daemon 1454 46* local stream fffffe0083ada1e0 <-> fffffe0083ada2d0 pacija dbus-daemon 1454 47* local stream fffffe0083f58c30 <-> fffffe0083ea8a50 pacija dbus-daemon 1454 48* local stream fffffe0006711960 <-> fffffe0083e053c0 pacija dbus-daemon 1454 50* local stream fffffe0083e044b0 <-> fffffe0083e045a0 pacija dbus-daemon 1454 52* local stream fffffe0083f59690 <-> fffffe0083bcac30 pacija dbus-launch 1453 root / 2 drwxr-xr-x 1024 r pacija dbus-launch 1453 wd / 2 drwxr-xr-x 1024 r pacija dbus-launch 1453 text / 3290779 -r-xr-xr-x 25752 r pacija dbus-launch 1453 ctty /dev 47 crw------- ttyv1 rw pacija dbus-launch 1453 0 /dev 47 crw------- ttyv1 rw pacija dbus-launch 1453 1 /dev 19 crw-rw-rw- null rw pacija dbus-launch 1453 2 /dev 19 crw-rw-rw- null rw pacija dbus-launch 1453 3* local stream fffffe00069723c0 <-> fffffe00069722d0 pacija dbus-launch 1453 4* local stream fffffe0006948c30 <-> fffffe0006948e10 pacija dbus-launch 1453 8* pipe fffffe0083299000 <-> fffffe0083299158 0 rw pacija xfce4-session 1450 root / 2 drwxr-xr-x 1024 r pacija xfce4-session 1450 wd / 3131772 drwxr-xr-x 6656 r pacija xfce4-session 1450 text / 3291345 -r-xr-xr-x 172240 r pacija xfce4-session 1450 ctty /dev 47 crw------- ttyv1 rw pacija xfce4-session 1450 0 /dev 47 crw------- ttyv1 rw pacija xfce4-session 1450 1 /dev 47 crw------- ttyv1 rw pacija xfce4-session 1450 2 /dev 47 crw------- ttyv1 rw pacija xfce4-session 1450 3* local stream fffffe00069721e0 <-> fffffe00069720f0 pacija xfce4-session 1450 4* pipe fffffe00066942d8 <-> fffffe0006694430 0 rw pacija xfce4-session 1450 5* pipe fffffe0006694430 <-> fffffe00066942d8 0 rw pacija xfce4-session 1450 6* local stream fffffe0006972000 <-> fffffe0006927e10 pacija xfce4-session 1450 7* local stream fffffe0006972780 pacija xfce4-session 1450 8* pipe fffffe0006535b60 <-> fffffe0006535cb8 0 rw pacija xfce4-session 1450 9* pipe fffffe0006535cb8 <-> fffffe0006535b60 0 rw pacija xfce4-session 1450 10* local stream fffffe0006927870 <-> fffffe0006927780 pacija xfce4-session 1450 11* local stream fffffe00834d3b40 <-> fffffe00069271e0 pacija xfce4-session 1450 12* local stream fffffe000670b1e0 <-> fffffe000670b2d0 pacija xfce4-session 1450 13* local stream fffffe00069481e0 <-> fffffe0006948000 pacija xfce4-session 1450 14* local stream fffffe008364f960 <-> fffffe008364fa50 pacija xfce4-session 1450 15* local stream fffffe0006948780 <-> fffffe0006948870 pacija xfce4-session 1450 16* local stream fffffe0083e0db40 <-> fffffe0083e0dc30 pacija xfce4-session 1450 17* local stream fffffe00069234b0 <-> fffffe0083ad94b0 pacija ck-launch-session 1434 root / 2 drwxr-xr-x 1024 r pacija ck-launch-session 1434 wd / 3131772 drwxr-xr-x 6656 r pacija ck-launch-session 1434 text / 3290723 -r-xr-xr-x 7280 r pacija ck-launch-session 1434 ctty /dev 47 crw------- ttyv1 rw pacija ck-launch-session 1434 0 /dev 47 crw------- ttyv1 rw pacija ck-launch-session 1434 1 /dev 47 crw------- ttyv1 rw pacija ck-launch-session 1434 2 /dev 47 crw------- ttyv1 rw pacija ck-launch-session 1434 3* local stream fffffe00069725a0 <-> fffffe00069724b0 pacija sh 1427 root / 2 drwxr-xr-x 1024 r pacija sh 1427 wd / 3131772 drwxr-xr-x 6656 r pacija sh 1427 text / 5698227 -r-xr-xr-x 146992 r pacija sh 1427 ctty /dev 47 crw------- ttyv1 rw pacija sh 1427 0 /dev 47 crw------- ttyv1 rw pacija sh 1427 1 /dev 47 crw------- ttyv1 rw pacija sh 1427 2 /dev 47 crw------- ttyv1 rw pacija sh 1427 10 / 4013106 -r--r--r-- 5709 r root hald-addon-storage 1421 root / 2 drwxr-xr-x 1024 r root hald-addon-storage 1421 wd / 3775353 drwxr-xr-x 3072 r root hald-addon-storage 1421 text / 3777674 -r-xr-xr-x 21112 r root hald-addon-storage 1421 0 /dev 19 crw-rw-rw- null r root hald-addon-storage 1421 1 /dev 19 crw-rw-rw- null rw root hald-addon-storage 1421 2 /dev 19 crw-rw-rw- null rw root hald-addon-storage 1421 3* local stream fffffe00069734b0 <-> fffffe0006973690 root hald-addon-storage 1421 4* local stream fffffe0006973870 <-> fffffe0006a59000 root hald-addon-mouse-s 1389 root / 2 drwxr-xr-x 1024 r root hald-addon-mouse-s 1389 wd / 3775353 drwxr-xr-x 3072 r root hald-addon-mouse-s 1389 text / 3777687 -r-xr-xr-x 14184 r root hald-addon-mouse-s 1389 0 /dev 19 crw-rw-rw- null r root hald-addon-mouse-s 1389 1 /dev 19 crw-rw-rw- null rw root hald-addon-mouse-s 1389 2 /dev 19 crw-rw-rw- null rw root hald-addon-mouse-s 1389 3* local stream fffffe000670bb40 <-> fffffe000670bc30 root Xorg 1385 root / 2 drwxr-xr-x 1024 r root Xorg 1385 wd / 3131772 drwxr-xr-x 6656 r root Xorg 1385 text / 3291363 -r-sr-xr-x 1892120 r root Xorg 1385 ctty /dev 47 crw------- ttyv1 rw root Xorg 1385 0 / 1284432 -rw-r--r-- 14295 w root Xorg 1385 1* internet6 stream tcp fffffe0006651b70 root Xorg 1385 2 /dev 47 crw------- ttyv1 rw root Xorg 1385 3* internet stream tcp fffffe00066517a0 root Xorg 1385 4* local stream fffffe000670a690 root Xorg 1385 5 / 3933634 -r--r--r-- 31246 r root Xorg 1385 6 /dev 21 crw-r--r-- pci rw root Xorg 1385 7 /dev 13 crw-r----- mem rw root Xorg 1385 8 /dev 54 crw------- ttyv8 rw root Xorg 1385 9 /dev 17 crw------- io rw root Xorg 1385 10 /dev 35 crw-rw-rw- nvidiactl rw root Xorg 1385 11 /dev 34 crw-rw-rw- nvidia0 rw root Xorg 1385 12 /dev 34 crw-rw-rw- nvidia0 rw root Xorg 1385 13 /dev 34 crw-rw-rw- nvidia0 rw root Xorg 1385 14 /dev 34 crw-rw-rw- nvidia0 rw root Xorg 1385 15 /dev 34 crw-rw-rw- nvidia0 rw root Xorg 1385 16 /dev 34 crw-rw-rw- nvidia0 rw root Xorg 1385 17 /dev 34 crw-rw-rw- nvidia0 rw root Xorg 1385 18* local stream fffffe00069231e0 <-> fffffe00069232d0 root Xorg 1385 19 /dev 35 crw-rw-rw- nvidiactl rw root Xorg 1385 20 /dev 34 crw-rw-rw- nvidia0 rw root Xorg 1385 21 /dev 34 crw-rw-rw- nvidia0 rw root Xorg 1385 22 /dev 34 crw-rw-rw- nvidia0 rw root Xorg 1385 23 /dev 35 crw-rw-rw- nvidiactl rw root Xorg 1385 24 /dev 34 crw-rw-rw- nvidia0 rw root Xorg 1385 25 /dev 34 crw-rw-rw- nvidia0 rw root Xorg 1385 26* local stream fffffe00069240f0 <-> fffffe0006923d20 root Xorg 1385 27* local stream fffffe000670bd20 <-> fffffe000670be10 root Xorg 1385 28 /dev 44 crw-rw-rw- psm0 rw root Xorg 1385 29* local stream fffffe00069722d0 <-> fffffe00069723c0 root Xorg 1385 30* local stream fffffe0006948e10 <-> fffffe0006948c30 root Xorg 1385 31* local stream fffffe00069720f0 <-> fffffe00069721e0 root Xorg 1385 32* local stream fffffe0006923e10 <-> fffffe000670a2d0 root Xorg 1385 33* local stream fffffe0006927a50 <-> fffffe0006927960 root Xorg 1385 34* local stream fffffe0006972960 <-> fffffe0006948d20 root Xorg 1385 35* local stream fffffe008364fb40 <-> fffffe008364fc30 root Xorg 1385 36* local stream fffffe00834d3960 <-> fffffe00834d3a50 root Xorg 1385 37* local stream fffffe0083ea9870 <-> fffffe0083ea9960 root Xorg 1385 38* local stream fffffe00069233c0 <-> fffffe0006a5a1e0 root Xorg 1385 39* local stream fffffe00835d0000 <-> fffffe00835d00f0 root Xorg 1385 40* local stream fffffe00069230f0 <-> fffffe0006924000 root Xorg 1385 41* local stream fffffe0083ea8e10 <-> fffffe0083ea9000 root Xorg 1385 42* local stream fffffe0006a59b40 <-> fffffe0006948690 root Xorg 1385 43* local stream fffffe0083ea83c0 <-> fffffe0083ea84b0 root Xorg 1385 44* local stream fffffe0083ad9000 <-> fffffe0083ea9780 root Xorg 1385 45* local stream fffffe0083e05000 <-> fffffe0083f58960 root Xorg 1385 46* local stream fffffe0083e0dd20 <-> fffffe0083e0de10 root Xorg 1385 47* local stream fffffe0083e05c30 <-> fffffe0083e04000 root Xorg 1385 48* local stream fffffe0083ea80f0 <-> fffffe00835d0780 root Xorg 1385 49* local stream fffffe0006924690 <-> fffffe0083e05d20 root Xorg 1385 50* local stream fffffe0083ea90f0 <-> fffffe0083e0cd20 pacija xinit 1383 root / 2 drwxr-xr-x 1024 r pacija xinit 1383 wd / 3131772 drwxr-xr-x 6656 r pacija xinit 1383 text / 3291995 -r-xr-xr-x 15696 r pacija xinit 1383 ctty /dev 47 crw------- ttyv1 rw pacija xinit 1383 0 /dev 47 crw------- ttyv1 rw pacija xinit 1383 1 /dev 47 crw------- ttyv1 rw pacija xinit 1383 2 /dev 47 crw------- ttyv1 rw pacija xinit 1383 3* local stream fffffe0006923d20 <-> fffffe00069240f0 root hald-runner 1381 root / 2 drwxr-xr-x 1024 r root hald-runner 1381 wd / 2 drwxr-xr-x 1024 r root hald-runner 1381 text / 3777605 -r-xr-xr-x 17664 r root hald-runner 1381 0 /dev 19 crw-rw-rw- null r root hald-runner 1381 1 /dev 19 crw-rw-rw- null rw root hald-runner 1381 2 /dev 19 crw-rw-rw- null rw root hald-runner 1381 3* local stream fffffe0006924a50 <-> fffffe0006924960 root hald-runner 1381 4* pipe fffffe00066f1888 <-> fffffe00066f19e0 0 rw root hald-runner 1381 5* pipe fffffe00066f19e0 <-> fffffe00066f1888 0 rw root hald-runner 1381 6* pipe fffffe000646a2d8 <-> fffffe000646a430 0 rw root hald-runner 1381 7* pipe fffffe000646a430 <-> fffffe000646a2d8 0 rw root hald-runner 1381 9* pipe fffffe00066f1430 <-> fffffe00066f12d8 0 rw root hald-runner 1381 12* pipe fffffe00065649e0 <-> fffffe0006564888 0 rw root hald-runner 1381 13* pipe fffffe0006564430 <-> fffffe00065642d8 0 rw root hald-runner 1381 14* pipe fffffe00066efcb8 <-> fffffe00066efb60 0 rw root hald-runner 1381 15* pipe fffffe00065679e0 <-> fffffe0006567888 0 rw root hald-runner 1381 16* pipe fffffe00065309e0 <-> fffffe0006530888 0 rw root hald-runner 1381 17* pipe fffffe0006564cb8 <-> fffffe0006564b60 0 rw root hald-runner 1381 18* pipe fffffe00066ef9e0 <-> fffffe00066ef888 0 rw root hald-runner 1381 19* pipe fffffe00066ef430 <-> fffffe00066ef2d8 0 rw root hald-runner 1381 20* pipe fffffe00066ee430 <-> fffffe00066ee2d8 0 rw root hald-runner 1381 21* pipe fffffe000668d430 <-> fffffe000668d2d8 0 rw root hald-runner 1381 22* pipe fffffe00066839e0 <-> fffffe0006683888 0 rw root hald-runner 1381 23* pipe fffffe0006530430 <-> fffffe00065302d8 0 rw root hald-runner 1381 24* pipe fffffe0006530708 <-> fffffe00065305b0 0 rw root hald-runner 1381 25* pipe fffffe00066e6708 <-> fffffe00066e65b0 0 rw root hald-runner 1381 26* pipe fffffe0006564708 <-> fffffe00065645b0 0 rw root hald-runner 1381 27* pipe fffffe0006564158 <-> fffffe0006564000 0 rw root hald-runner 1381 28* pipe fffffe0006429708 <-> fffffe00064295b0 0 rw root hald-runner 1381 29* pipe fffffe0006447430 <-> fffffe00064472d8 0 rw root hald-runner 1381 30* pipe fffffe0006683708 <-> fffffe00066835b0 0 rw root hald-runner 1381 31* pipe fffffe0006513708 <-> fffffe00065135b0 0 rw root hald-runner 1381 32* pipe fffffe0006683158 <-> fffffe0006683000 0 rw root hald-runner 1381 33* pipe fffffe0006513430 <-> fffffe00065132d8 0 rw root hald-runner 1381 34* pipe fffffe0083129cb8 <-> fffffe0083129b60 0 rw root hald-runner 1381 35* pipe fffffe0083129708 <-> fffffe00831295b0 0 rw root hald-runner 1381 36* pipe fffffe0083129158 <-> fffffe0083129000 0 rw root hald-runner 1381 37* pipe fffffe00831229e0 <-> fffffe0083122888 0 rw root hald-runner 1381 38* pipe fffffe0083122430 <-> fffffe00831222d8 0 rw root hald-runner 1381 39* pipe fffffe008310dcb8 <-> fffffe008310db60 0 rw root hald-runner 1381 40* pipe fffffe008310d708 <-> fffffe008310d5b0 0 rw root hald-runner 1381 41* pipe fffffe008310d158 <-> fffffe008310d000 0 rw root hald-runner 1381 42* pipe fffffe00065ab708 <-> fffffe00065ab5b0 0 rw root hald-runner 1381 43* pipe fffffe00065ab158 <-> fffffe00065ab000 0 rw root hald-runner 1381 44* pipe fffffe00065ab9e0 <-> fffffe00065ab888 0 rw root hald-runner 1381 45* pipe fffffe00066ef708 <-> fffffe00066ef5b0 0 rw haldaemo hald 1380 root / 2 drwxr-xr-x 1024 r haldaemo hald 1380 wd / 2 drwxr-xr-x 1024 r haldaemo hald 1380 text / 3777567 -r-xr-xr-x 290696 r haldaemo hald 1380 0 /dev 19 crw-rw-rw- null rw haldaemo hald 1380 1 /dev 19 crw-rw-rw- null rw haldaemo hald 1380 2 /dev 19 crw-rw-rw- null rw haldaemo hald 1380 3* pipe fffffe0006447888 <-> fffffe00064479e0 0 rw haldaemo hald 1380 4* pipe fffffe00064479e0 <-> fffffe0006447888 0 rw haldaemo hald 1380 7* pipe fffffe00066e62d8 <-> fffffe00066e6430 0 rw haldaemo hald 1380 8* pipe fffffe00066e6430 <-> fffffe00066e62d8 0 rw haldaemo hald 1380 9* local stream fffffe0006924d20 haldaemo hald 1380 10* local stream fffffe0006924c30 <-> fffffe0006924b40 haldaemo hald 1380 11* local stream fffffe0006711c30 haldaemo hald 1380 12* pipe fffffe00066ee888 <-> fffffe00066ee9e0 0 rw haldaemo hald 1380 13* pipe fffffe00066ee9e0 <-> fffffe00066ee888 0 rw haldaemo hald 1380 14* local stream fffffe0006924960 <-> fffffe0006924a50 haldaemo hald 1380 16 /dev 21 crw-r--r-- pci rw haldaemo hald 1380 17 /dev 67 crw-rw-rw- xpt0 rw haldaemo hald 1380 19 / 2983274 -r--r--r-- 403 r haldaemo hald 1380 20 / 4096648 drwxr-xr-x 512 r haldaemo hald 1380 21 / 1372505 -rw-rw-r-- 0 r haldaemo hald 1380 22 / 2982638 drwxr-xr-x 512 r haldaemo hald 1380 23 / 2982647 drwxr-xr-x 512 r haldaemo hald 1380 24 / 2982646 drwxr-xr-x 512 r haldaemo hald 1380 25 / 2982648 drwxr-xr-x 512 r haldaemo hald 1380 26 / 2982615 drwxr-xr-x 512 r haldaemo hald 1380 27 / 2982618 drwxr-xr-x 512 r haldaemo hald 1380 28 / 2982616 drwxr-xr-x 512 r haldaemo hald 1380 29 / 2982617 -r--r--r-- 1648 r haldaemo hald 1380 30 / 2982621 drwxr-xr-x 512 r haldaemo hald 1380 31 / 2982623 drwxr-xr-x 512 r haldaemo hald 1380 32 / 2982636 drwxr-xr-x 512 r haldaemo hald 1380 33 / 2982624 drwxr-xr-x 512 r haldaemo hald 1380 34 / 2982635 -r--r--r-- 1603 r haldaemo hald 1380 35 / 2982634 -r--r--r-- 20371 r haldaemo hald 1380 36 / 2982633 -r--r--r-- 1214 r haldaemo hald 1380 37 / 2982632 -r--r--r-- 1028 r haldaemo hald 1380 38 / 2982631 -r--r--r-- 1236 r haldaemo hald 1380 39 / 2982630 -r--r--r-- 1767 r haldaemo hald 1380 40 / 2982629 -r--r--r-- 4032 r haldaemo hald 1380 41 / 2982652 -r--r--r-- 257 r haldaemo hald 1380 42 / 2982628 -r--r--r-- 390 r haldaemo hald 1380 43 / 2982627 -r--r--r-- 1661 r haldaemo hald 1380 44 / 2982625 -r--r--r-- 795 r haldaemo hald 1380 45 / 2982626 -r--r--r-- 720 r haldaemo hald 1380 46 / 2982637 drwxr-xr-x 512 r haldaemo hald 1380 47* local stream fffffe0006711b40 <-> fffffe0006711a50 haldaemo hald 1380 48* local stream fffffe000670bc30 <-> fffffe000670bb40 haldaemo hald 1380 49* local stream fffffe0006973690 <-> fffffe00069734b0 pacija tcsh 1379 root / 2 drwxr-xr-x 1024 r pacija tcsh 1379 wd / 3131772 drwxr-xr-x 6656 r pacija tcsh 1379 text / 5698189 -r-xr-xr-x 382392 r pacija tcsh 1379 ctty /dev 47 crw------- ttyv1 rw pacija tcsh 1379 6 / 3151953 -rw-r--r-- 1450 r pacija tcsh 1379 15 /dev 47 crw------- ttyv1 rw pacija tcsh 1379 16 /dev 47 crw------- ttyv1 rw pacija tcsh 1379 17 /dev 47 crw------- ttyv1 rw pacija tcsh 1379 18 /dev 47 crw------- ttyv1 rw pacija tcsh 1379 19 /dev 47 crw------- ttyv1 rw root getty 1374 root / 2 drwxr-xr-x 1024 r root getty 1374 wd / 2 drwxr-xr-x 1024 r root getty 1374 text / 3174150 -r-xr-xr-x 28192 r root getty 1374 ctty /dev 53 crw------- ttyv7 rw root getty 1374 0 /dev 53 crw------- ttyv7 rw root getty 1374 1 /dev 53 crw------- ttyv7 rw root getty 1374 2 /dev 53 crw------- ttyv7 rw root getty 1373 root / 2 drwxr-xr-x 1024 r root getty 1373 wd / 2 drwxr-xr-x 1024 r root getty 1373 text / 3174150 -r-xr-xr-x 28192 r root getty 1373 ctty /dev 52 crw------- ttyv6 rw root getty 1373 0 /dev 52 crw------- ttyv6 rw root getty 1373 1 /dev 52 crw------- ttyv6 rw root getty 1373 2 /dev 52 crw------- ttyv6 rw root getty 1372 root / 2 drwxr-xr-x 1024 r root getty 1372 wd / 2 drwxr-xr-x 1024 r root getty 1372 text / 3174150 -r-xr-xr-x 28192 r root getty 1372 ctty /dev 51 crw------- ttyv5 rw root getty 1372 0 /dev 51 crw------- ttyv5 rw root getty 1372 1 /dev 51 crw------- ttyv5 rw root getty 1372 2 /dev 51 crw------- ttyv5 rw root getty 1371 root / 2 drwxr-xr-x 1024 r root getty 1371 wd / 2 drwxr-xr-x 1024 r root getty 1371 text / 3174150 -r-xr-xr-x 28192 r root getty 1371 ctty /dev 50 crw------- ttyv4 rw root getty 1371 0 /dev 50 crw------- ttyv4 rw root getty 1371 1 /dev 50 crw------- ttyv4 rw root getty 1371 2 /dev 50 crw------- ttyv4 rw root getty 1370 root / 2 drwxr-xr-x 1024 r root getty 1370 wd / 2 drwxr-xr-x 1024 r root getty 1370 text / 3174150 -r-xr-xr-x 28192 r root getty 1370 ctty /dev 49 crw------- ttyv3 rw root getty 1370 0 /dev 49 crw------- ttyv3 rw root getty 1370 1 /dev 49 crw------- ttyv3 rw root getty 1370 2 /dev 49 crw------- ttyv3 rw root getty 1369 root / 2 drwxr-xr-x 1024 r root getty 1369 wd / 2 drwxr-xr-x 1024 r root getty 1369 text / 3174150 -r-xr-xr-x 28192 r root getty 1369 ctty /dev 48 crw------- ttyv2 rw root getty 1369 0 /dev 48 crw------- ttyv2 rw root getty 1369 1 /dev 48 crw------- ttyv2 rw root getty 1369 2 /dev 48 crw------- ttyv2 rw root login 1368 root / 2 drwxr-xr-x 1024 r root login 1368 wd / 3131772 drwxr-xr-x 6656 r root login 1368 text / 3068575 -r-sr-xr-x 25256 r root login 1368 ctty /dev 47 crw------- ttyv1 rw root login 1368 0 /dev 47 crw------- ttyv1 rw root login 1368 1 /dev 47 crw------- ttyv1 rw root login 1368 2 /dev 47 crw------- ttyv1 rw root login 1368 3* local dgram fffffe000670a780 <-> fffffe00069274b0 root getty 1367 root / 2 drwxr-xr-x 1024 r root getty 1367 wd / 2 drwxr-xr-x 1024 r root getty 1367 text / 3174150 -r-xr-xr-x 28192 r root getty 1367 ctty /dev 46 crw------- ttyv0 rw root getty 1367 0 /dev 46 crw------- ttyv0 rw root getty 1367 1 /dev 46 crw------- ttyv0 rw root getty 1367 2 /dev 46 crw------- ttyv0 rw root cron 1317 root / 2 drwxr-xr-x 1024 r root cron 1317 wd / 1284103 drwxr-x--- 512 r root cron 1317 text / 3067289 -r-xr-xr-x 41496 r root cron 1317 0 /dev 19 crw-rw-rw- null rw root cron 1317 1 /dev 19 crw-rw-rw- null rw root cron 1317 2 /dev 19 crw-rw-rw- null rw root cron 1317 3 / 1284404 -rw------- 4 w smmsp sendmail 1312 root / 2 drwxr-xr-x 1024 r smmsp sendmail 1312 wd / 1284126 drwxrwx--- 512 r smmsp sendmail 1312 text / 3069064 -r-xr-sr-x 719464 r smmsp sendmail 1312 0 /dev 19 crw-rw-rw- null r smmsp sendmail 1312 1 /dev 19 crw-rw-rw- null w smmsp sendmail 1312 2 /dev 19 crw-rw-rw- null w smmsp sendmail 1312 3* local dgram fffffe0006924e10 <-> fffffe00069275a0 smmsp sendmail 1312 4 / 1284403 -rw------- 50 w root sendmail 1309 root / 2 drwxr-xr-x 1024 r root sendmail 1309 wd / 1284123 drwxr-xr-x 512 r root sendmail 1309 text / 3069064 -r-xr-sr-x 719464 r root sendmail 1309 0 /dev 19 crw-rw-rw- null r root sendmail 1309 1 /dev 19 crw-rw-rw- null w root sendmail 1309 2 /dev 19 crw-rw-rw- null w root sendmail 1309 3* local dgram fffffe0006711d20 <-> fffffe00069274b0 root sendmail 1309 4* internet stream tcp fffffe0006cae7a0 root sendmail 1309 5 / 1284398 -rw------- 79 w root sshd 1306 root / 2 drwxr-xr-x 1024 r root sshd 1306 wd / 2 drwxr-xr-x 1024 r root sshd 1306 text / 3055112 -r-xr-xr-x 286136 r root sshd 1306 0 /dev 19 crw-rw-rw- null rw root sshd 1306 1 /dev 19 crw-rw-rw- null rw root sshd 1306 2 /dev 19 crw-rw-rw- null rw root sshd 1306 3* internet6 stream tcp fffffe0006c1eb70 root sshd 1306 4* internet stream tcp fffffe0006c1e7a0 root polkitd 1282 root / 2 drwxr-xr-x 1024 r root polkitd 1282 wd / 2 drwxr-xr-x 1024 r root polkitd 1282 text / 3777485 -r-xr-xr-x 9264 r root polkitd 1282 0 /dev 19 crw-rw-rw- null rw root polkitd 1282 1 /dev 19 crw-rw-rw- null rw root polkitd 1282 2 /dev 19 crw-rw-rw- null rw root polkitd 1282 3* pipe fffffe000646a5b0 <-> fffffe000646a708 0 rw root polkitd 1282 4* pipe fffffe000646a708 <-> fffffe000646a5b0 0 rw root polkitd 1282 5 / 3633759 drwxr-xr-x 512 r root polkitd 1282 6 / 4739228 drwxr-xr-x 512 r root polkitd 1282 7 / 3936388 drwxr-xr-x 512 r root polkitd 1282 8* local stream fffffe00069270f0 <-> fffffe0006927000 root polkitd 1282 9* pipe fffffe00066e7888 <-> fffffe00066e79e0 0 rw root polkitd 1282 10* pipe fffffe00066e79e0 <-> fffffe00066e7888 0 rw root polkitd 1282 11* pipe fffffe00066832d8 <-> fffffe0006683430 0 rw root polkitd 1282 12* pipe fffffe0006683430 <-> fffffe00066832d8 0 rw root polkitd 1282 13 / 4012848 drwxr-xr-x 512 r root polkitd 1282 15* local stream fffffe000670b870 <-> fffffe000670b960 root polkitd 1282 16* local stream fffffe000670b960 <-> fffffe000670b870 root polkitd 1282 17 / 1370232 -rw-r--r-- 554 r root polkitd 1282 18 / 2981366 drwxr-xr-x 512 r root polkitd 1282 19 / 1372229 drwxr-xr-x 512 r root polkitd 1282 20 / 2981351 drwxr-xr-x 512 r root polkitd 1282 21 / 1372945 drwxr-xr-x 512 r root polkitd 1282 22 / 2981354 drwxr-xr-x 512 r root polkitd 1282 23 / 1373119 drwxr-xr-x 512 r root polkitd 1282 24 / 2981355 drwxr-xr-x 512 r root polkitd 1282 25 / 1373453 drwxr-xr-x 512 r root polkitd 1282 26 / 3553497 drwxr-xr-x 512 r root polkitd 1282 27 / 1376048 drwxr-xr-x 512 r root polkitd 1282 28 / 2981356 drwxr-xr-x 512 r root polkitd 1282 29 / 1371370 drwxr-xr-x 512 r root polkitd 1282 30 / 3553493 drwx------ 512 r root console-kit-daemon 1280 root / 2 drwxr-xr-x 1024 r root console-kit-daemon 1280 wd / 2 drwxr-xr-x 1024 r root console-kit-daemon 1280 text / 3777536 -r-xr-xr-x 133352 r root console-kit-daemon 1280 0 /dev 19 crw-rw-rw- null rw root console-kit-daemon 1280 1 /dev 19 crw-rw-rw- null rw root console-kit-daemon 1280 2 /dev 19 crw-rw-rw- null rw root console-kit-daemon 1280 3* pipe fffffe00066e6b60 <-> fffffe00066e6cb8 0 rw root console-kit-daemon 1280 4* pipe fffffe00066e6cb8 <-> fffffe00066e6b60 0 rw root console-kit-daemon 1280 5 / 3633759 drwxr-xr-x 512 r root console-kit-daemon 1280 6 / 4739228 drwxr-xr-x 512 r root console-kit-daemon 1280 7 / 3936388 drwxr-xr-x 512 r root console-kit-daemon 1280 8* pipe fffffe0006694b60 <-> fffffe0006694cb8 0 rw root console-kit-daemon 1280 9* pipe fffffe0006694cb8 <-> fffffe0006694b60 0 rw root console-kit-daemon 1280 10* local stream fffffe0006a59a50 <-> fffffe0006a59960 root console-kit-daemon 1280 11 / 1376486 -rw-r--r-- 3824 w root console-kit-daemon 1280 12* local stream fffffe000670aa50 <-> fffffe000670a960 root console-kit-daemon 1280 13 - - bad - root console-kit-daemon 1280 14* pipe fffffe00066ee000 <-> fffffe00066ee158 0 rw root console-kit-daemon 1280 15* pipe fffffe00066ee158 <-> fffffe00066ee000 0 rw root console-kit-daemon 1280 16* pipe fffffe008396a2d8 <-> fffffe008396a430 0 rw root console-kit-daemon 1280 17* pipe fffffe008396a430 <-> fffffe008396a2d8 0 rw root console-kit-daemon 1280 20* local dgram fffffe000670a870 <-> fffffe00069274b0 messageb dbus-daemon 1259 root / 2 drwxr-xr-x 1024 r messageb dbus-daemon 1259 wd / 2 drwxr-xr-x 1024 r messageb dbus-daemon 1259 text / 3290566 -r-xr-xr-x 382392 r messageb dbus-daemon 1259 0 /dev 19 crw-rw-rw- null rw messageb dbus-daemon 1259 1 /dev 19 crw-rw-rw- null rw messageb dbus-daemon 1259 2 /dev 19 crw-rw-rw- null rw messageb dbus-daemon 1259 3* local stream fffffe000670ab40 messageb dbus-daemon 1259 5 / 3633759 drwxr-xr-x 512 r messageb dbus-daemon 1259 6 / 4739228 drwxr-xr-x 512 r messageb dbus-daemon 1259 7 / 3936388 drwxr-xr-x 512 r messageb dbus-daemon 1259 8* local stream fffffe0006a5a000 <-> fffffe0006a59e10 messageb dbus-daemon 1259 9* local stream fffffe0006a59e10 <-> fffffe0006a5a000 messageb dbus-daemon 1259 10* local stream fffffe0006924b40 <-> fffffe0006924c30 messageb dbus-daemon 1259 11* local dgram fffffe0006a59d20 <-> fffffe00069275a0 messageb dbus-daemon 1259 12* local stream fffffe0006a59000 <-> fffffe0006973870 messageb dbus-daemon 1259 13* local stream fffffe0006a59960 <-> fffffe0006a59a50 messageb dbus-daemon 1259 14* local stream fffffe000670be10 <-> fffffe000670bd20 messageb dbus-daemon 1259 15* local stream fffffe000670a960 <-> fffffe000670aa50 messageb dbus-daemon 1259 16* local stream fffffe00069724b0 <-> fffffe00069725a0 messageb dbus-daemon 1259 17* local stream fffffe0006927000 <-> fffffe00069270f0 messageb dbus-daemon 1259 18* local stream fffffe000670a000 <-> fffffe000670a0f0 messageb dbus-daemon 1259 19* local stream fffffe0006972a50 <-> fffffe0006973e10 messageb dbus-daemon 1259 20* local stream fffffe0006973c30 <-> fffffe0006973a50 messageb dbus-daemon 1259 21* local stream fffffe00834d3870 <-> fffffe0006a5a2d0 messageb dbus-daemon 1259 22* local stream fffffe0006923690 <-> fffffe0006923780 messageb dbus-daemon 1259 23* local stream fffffe0006948870 <-> fffffe0006948780 messageb dbus-daemon 1259 24* local stream fffffe000670a5a0 <-> fffffe0006a594b0 messageb dbus-daemon 1259 25* local stream fffffe008364f000 <-> fffffe008364f0f0 noip noip2 1252 root / 2 drwxr-xr-x 1024 r noip noip2 1252 wd / 2 drwxr-xr-x 1024 r noip noip2 1252 text / 3292444 -r-xr-xr-x 49288 r noip noip2 1252 0* local dgram fffffe000670ac30 <-> fffffe00069275a0 noip noip2 1252 3 / 3370905 -rw------- 164 rw root in.tftpd 1245 root / 2 drwxr-xr-x 1024 r root in.tftpd 1245 wd / 4737543 drwxrwxrwx 512 r root in.tftpd 1245 text / 3773515 -r-xr-xr-x 37656 r root in.tftpd 1245 0 /dev 19 crw-rw-rw- null rw root in.tftpd 1245 1 /dev 19 crw-rw-rw- null rw root in.tftpd 1245 2 /dev 19 crw-rw-rw- null rw root in.tftpd 1245 3* local dgram fffffe0006972e10 <-> fffffe00069274b0 root in.tftpd 1245 4* internet dgram udp fffffe00066f4930 root in.tftpd 1245 5* internet6 dgram udp fffffe00066f47a8 root powerd 1226 root / 2 drwxr-xr-x 1024 r root powerd 1226 wd / 2 drwxr-xr-x 1024 r root powerd 1226 text / 3068888 -r-xr-xr-x 15784 r root powerd 1226 0 /dev 19 crw-rw-rw- null rw root powerd 1226 1 /dev 19 crw-rw-rw- null rw root powerd 1226 2 /dev 19 crw-rw-rw- null rw root powerd 1226 3 / 1284416 -rw------- 4 w root powerd 1226 4* local stream fffffe0006923000 <-> fffffe0006711e10 root ntpd 1223 root / 2 drwxr-xr-x 1024 r root ntpd 1223 wd / 2 drwxr-xr-x 1024 r root ntpd 1223 text / 3068185 -r-xr-xr-x 392552 r root ntpd 1223 0 /dev 19 crw-rw-rw- null rw root ntpd 1223 1 /dev 19 crw-rw-rw- null rw root ntpd 1223 2 /dev 19 crw-rw-rw- null rw root ntpd 1223 3* local dgram fffffe000670b5a0 <-> fffffe00069274b0 root ntpd 1223 20* internet dgram udp fffffe00066e2c40 root ntpd 1223 21* internet6 dgram udp fffffe00066e2ab8 root ntpd 1223 22* internet6 dgram udp fffffe00066e27a8 root ntpd 1223 23* internet6 dgram udp fffffe00066e2498 root ntpd 1223 24* internet dgram udp fffffe00066e2310 root ntpd 1223 25* internet dgram udp fffffe00066cc620 root ntpd 1223 26* route raw 0 fffffe0006729550 root syslogd 1138 root / 2 drwxr-xr-x 1024 r root syslogd 1138 wd / 2 drwxr-xr-x 1024 r root syslogd 1138 text / 3070283 -r-xr-xr-x 40944 r root syslogd 1138 0 /dev 19 crw-rw-rw- null rw root syslogd 1138 1 /dev 19 crw-rw-rw- null rw root syslogd 1138 2 /dev 19 crw-rw-rw- null rw root syslogd 1138 3 / 1284405 -rw------- 4 w root syslogd 1138 4* local dgram fffffe00069275a0 root syslogd 1138 5* local dgram fffffe00069274b0 root syslogd 1138 6* internet6 dgram udp fffffe00066ccc40 root syslogd 1138 7* internet dgram udp fffffe00066ccab8 root syslogd 1138 8 /dev 16 crw------- klog r root syslogd 1138 10 /dev 4 crw------- console w root syslogd 1138 11 / 1284135 -rw-r--r-- 50842 w root syslogd 1138 12 / 1284188 -rw------- 59 w root syslogd 1138 13 / 1284215 -rw------- 17065 w root syslogd 1138 14 / 1284204 -rw-r----- 1279 w root syslogd 1138 15 / 1284184 -rw-r--r-- 59 w root syslogd 1138 16 / 1284189 -rw------- 149 w root syslogd 1138 17 / 1284361 -rw------- 688 w root syslogd 1138 18 / 1284183 -rw------- 12763 w root syslogd 1138 19 / 1284187 -rw-r----- 88248 w root devd 914 root / 2 drwxr-xr-x 1024 r root devd 914 wd / 2 drwxr-xr-x 1024 r root devd 914 text / 1847395 -r-xr-xr-x 465528 r root devd 914 0 /dev 19 crw-rw-rw- null rw root devd 914 1 /dev 19 crw-rw-rw- null rw root devd 914 2 /dev 19 crw-rw-rw- null rw root devd 914 3 /dev 6 crw------- devctl r root devd 914 4* local stream fffffe0006927d20 root devd 914 5 / 1284385 -rw------- 3 w root devd 914 6* local stream fffffe0006711e10 -> fffffe0006923000 root devd 914 7* local stream fffffe0006711a50 -> fffffe0006711b40 root devd 914 8* local stream fffffe00069232d0 -> fffffe00069231e0 root devd 914 9* local stream fffffe00834d35a0 -> fffffe00834d3690 root ng_queue 811 root / 2 drwxr-xr-x 1024 r root ng_queue 811 wd / 2 drwxr-xr-x 1024 r root adjkerntz 167 root / 2 drwxr-xr-x 1024 r root adjkerntz 167 wd / 2 drwxr-xr-x 1024 r root adjkerntz 167 text / 1847374 -r-xr-xr-x 9400 r root adjkerntz 167 0 /dev 19 crw-rw-rw- null rw root adjkerntz 167 1 /dev 19 crw-rw-rw- null rw root adjkerntz 167 2 /dev 19 crw-rw-rw- null rw root init 1 root / 2 drwxr-xr-x 1024 r root init 1 wd / 2 drwxr-xr-x 1024 r root init 1 text / 1847408 -r-xr-xr-x 799088 r root kernel 0 root / 2 drwxr-xr-x 1024 r root kernel 0 wd / 2 drwxr-xr-x 1024 r ------------------------------------------------------------------------ dmesg Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.2-PRERELEASE #0 r254557: Sun Aug 25 22:44:52 CEST 2013 pacija@kaa.mimar.rs:/usr/obj/usr/src/sys/KAAGEN amd64 gcc version 4.2.1 20070831 patched [FreeBSD] CPU: Intel(R) Core(TM) i7 CPU Q 740 @ 1.73GHz (1729.04-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106e5 Family = 0x6 Model = 0x1e Stepping = 5 Features=0xbfebfbff Features2=0x98e3fd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3989553152 (3804 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <_ASUS_ Notebook> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ACPI Warning: 32/64X FACS address mismatch in FADT - 0xBB5B3F40/0x00000000BB5CDD40, using 32 (20110527/tbfadt-517) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <_ASUS_ Notebook> on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 3.0 on pci0 pci1: on pcib1 vgapci0: port 0xd000-0xd07f mem 0xd2000000-0xd2ffffff,0xc0000000-0xcfffffff,0xd0000000-0xd1ffffff irq 16 at device 0.0 on pci1 acpi_video0: on vgapci0 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xd3080000-0xd3083fff irq 17 at device 0.1 on pci1 pci0: at device 8.0 (no driver attached) pci0: at device 8.1 (no driver attached) pci0: at device 8.2 (no driver attached) pci0: at device 8.3 (no driver attached) pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) pci0: at device 22.0 (no driver attached) ehci0: mem 0xd9608000-0xd96083ff irq 16 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 hdac1: mem 0xd9600000-0xd9603fff irq 22 at device 27.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 17 at device 28.1 on pci0 pci3: on pcib3 ath0: mem 0xd6e00000-0xd6e0ffff irq 17 at device 0.0 on pci3 ath0: AR9285 mac 192.2 RF5133 phy 14.0 pcib4: irq 19 at device 28.3 on pci0 pci4: on pcib4 xhci0: mem 0xd5a00000-0xd5a0ffff irq 19 at device 0.0 on pci4 xhci0: 32 byte context size. usbus1 on xhci0 pcib5: irq 16 at device 28.4 on pci0 pci5: on pcib5 pcib6: irq 17 at device 28.5 on pci0 pci6: on pcib6 alc0: port 0x8000-0x807f mem 0xd3200000-0xd323ffff irq 17 at device 0.0 on pci6 alc0: 15872 Tx FIFO, 15360 Rx FIFO alc0: Using 1 MSI message(s). miibus0: on alc0 atphy0: PHY 0 on miibus0 atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow alc0: Ethernet address: 48:5b:39:9b:e8:e0 ehci1: mem 0xd9607000-0xd96073ff irq 23 at device 29.0 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci1 pcib7: at device 30.0 on pci0 pci7: on pcib7 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xe070-0xe077,0xe060-0xe063,0xe050-0xe057,0xe040-0xe043,0xe020-0xe03f mem 0xd9606000-0xd96067ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 4 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich5: at channel 5 on ahci0 pcib8: on acpi0 pci255: on pcib8 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 est1: on cpu1 est2: on cpu2 est3: on cpu3 est4: on cpu4 est5: on cpu5 est6: on cpu6 est7: on cpu7 Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x4da offMax=0x727 hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 5 on hdaa0 hdacc1: at cad 1 on hdac0 hdaa1: at nid 1 on hdacc1 pcm1: at nid 5 on hdaa1 hdacc2: at cad 2 on hdac0 hdaa2: at nid 1 on hdacc2 pcm2: at nid 5 on hdaa2 hdacc3: at cad 3 on hdac0 hdaa3: at nid 1 on hdacc3 pcm3: at nid 5 on hdaa3 hdacc4: at cad 0 on hdac1 hdaa4: at nid 1 on hdacc4 pcm4: at nid 27,33 and 24,25 on hdaa4 pcm5: at nid 30 on hdaa4 usbus0: 480Mbps High Speed USB v2.0 usbus1: 5.0Gbps Super Speed USB v3.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: <0x1b73> at usbus1 uhub1: <0x1b73 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 610480MB (1250263728 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #1 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #6 Launched! Timecounter "TSC" frequency 1729038786 Hz quality 1000 uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 usbus0 uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 usbus0 ugen0.2: at usbus0 uhub3: on usbus0 ugen2.2: at usbus2 uhub4: on usbus2 Root mount waiting for: usbus2 usbus0 uhub3: 6 ports with 6 removable, self powered uhub4: 8 ports with 8 removable, self powered ugen0.3: at usbus0 ugen0.4: at usbus0 Root mount waiting for: usbus0 Trying to mount root from ufs:/dev/ada0s2a [rw]... Setting hostuuid: 0009d6cf-5000-8009-ffff-485b399be8e0. Setting hostid: 0x4538276e. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/ada0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s2a: clean, 3844654 free (163070 frags, 460198 blocks, 1.4% fragmentation) /dev/ada0s3: FILESYSTEM CLEAN; SKIPPING CHECKS Mounting local file systems:. Setting hostname: kaa.mimar.rs. wlan0: Ethernet address: 48:5d:60:5f:96:e6 Starting wpa_supplicant. Starting Network: lo0 ath0 alc0. lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 ath0: flags=8843 metric 0 mtu 2290 ether 48:5d:60:5f:96:e6 nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated alc0: flags=8843 metric 0 mtu 1500 options=c3198 ether 48:5b:39:9b:e8:e0 nd6 options=29 media: Ethernet autoselect (none) status: no carrier Starting devd. ubt0: on usbus0 WARNING: attempt to domain_add(bluetooth) after domainfinalize() WARNING: attempt to domain_add(netgraph) after domainfinalize() Starting dhclient. DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.1 bound to 192.168.1.10 -- renewal in 2147483647 seconds. add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/kde4/lib /usr/local/lib/alsa-lib /usr/local/lib/event2 /usr/local/lib/ffmpeg1 /usr/local/lib/gegl-0.2 /usr/local/lib/graphviz /usr/local/lib/nss /usr/local/lib/pth /usr/local/lib/qt4 /usr/local/lib/virtualbox 32-bit compatibility ldconfig path: /usr/lib32 Creating and/or trimming log files. Starting syslogd. No core dumps found. Additional ABI support: linux. Clearing /tmp (X related). Recovering vi editor sessions:. Updating motd:. Starting fusefs. fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.19 Starting ntpd. Starting powerd. Starting tftpd. Starting noip. Starting dbus. Starting hald. Configuring syscons: keymap blanktime. Performing sanity check on sshd configuration. Starting sshd. Starting cron. Starting background file system checks in 60 seconds. Tue Aug 27 09:13:03 CEST 2013 Aug 27 09:13:24 kaa dbus[1259]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.15" (uid=1001 pid=1465 comm="nautilus --sm-client-id 25bdad1e0-0659-11e3-bd1e-4") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination=":1.1" (uid=0 pid=1280 comm="/usr/local/sbin/console-kit-daemon --no-daemon ") Aug 27 09:43:15 kaa noip2[1252]: Can't gethostbyname for dynupdate.no-ip.com Aug 27 09:43:15 kaa noip2[1252]: Can't get our visible IP address from ip1.dynupdate.no-ip.com tun0: link state changed to UP Aug 27 10:12:17 kaa ppp[1646]: Alert: deflink: Can't create /var/run/pts/1.if: No such file or directory Aug 27 10:14:41 kaa gnome-keyring-daemon[1672]: couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files Aug 27 10:14:41 kaa gnome-keyring-daemon[1672]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk Aug 27 10:29:39 kaa gnome-keyring-prompt: couldn't allocate secure memory to keep passwords and or keys from being written to the disk Aug 27 10:29:39 kaa gnome-keyring-daemon[1672]: ** Message: couldn't allocate secure memory to keep passwords and or keys from being written to the disk wlan0: link state changed to DOWN Aug 27 10:33:25 kaa ppp[1646]: Alert: deflink: Can't remove /var/run/pts/1.if: No such file or directory tun0: link state changed to DOWN wlan0: link state changed to UP tun0: link state changed to UP Aug 27 10:33:40 kaa ppp[1805]: Alert: deflink: Can't create /var/run/pts/1.if: No such file or directory wlan0: promiscuous mode enabled wlan0: link state changed to DOWN Aug 27 12:29:57 kaa ppp[1805]: Alert: deflink: Can't remove /var/run/pts/1.if: No such file or directory tun0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN Aug 27 12:31:34 kaa dhclient[875]: connection closed Aug 27 12:31:34 kaa dhclient[875]: exiting. wlan0: Ethernet address: 48:5d:60:5f:96:e6 wlan0: link state changed to UP Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xffffff8127951580 frame pointer = 0x28:0xffffff81279515b0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1929 (VirtualBox) trap number = 12 panic: page fault cpuid = 2 KDB: stack backtrace: #0 0xffffffff80948356 at kdb_backtrace+0x66 #1 0xffffffff8090deae at panic+0x1ce #2 0xffffffff80cf2c00 at trap_fatal+0x290 #3 0xffffffff80cf2f61 at trap_pfault+0x211 #4 0xffffffff80cf3514 at trap+0x344 #5 0xffffffff80cdc843 at calltrap+0x8 #6 0xffffffff8285cd5e at vboxNetFltPortOsXmit+0xee #7 0xffffffff8285dcb4 at vboxNetFltPortXmit+0x64 #8 0xffffffff828c83f8 at fuse_germ_vnops+0x55cf8 #9 0xffffffff828ca182 at fuse_germ_vnops+0x57a82 #10 0xffffffff828caf12 at fuse_germ_vnops+0x58812 #11 0xffffffff82889647 at fuse_germ_vnops+0x16f47 #12 0xffffffff828898a8 at fuse_germ_vnops+0x171a8 #13 0xffffffff825963b2 at supdrvIOCtl+0x1d12 #14 0xffffffff8259bef0 at VBoxDrvFreeBSDIOCtl+0x1d0 #15 0xffffffff807f4cbb at devfs_ioctl_f+0x7b #16 0xffffffff8095ae16 at kern_ioctl+0x106 #17 0xffffffff8095b05d at sys_ioctl+0xfd Uptime: 3h19m29s Dumping 734 out of 3984 MB:..3%..11%..22%..31%..42%..51%..61%..72%..81%..92% ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident GENERIC machine amd64 cpu HAMMER makeoptions WITH_CTF=1 makeoptions DEBUG=-g options USB_DEBUG options RDRAND_RNG options PADLOCK_RNG options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options SC_PIXEL_MODE options VESA options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options ATA_CAM options SMP options DDB_CTF options KDB_TRACE options KDB options INCLUDE_CONFIG_FILE options KDTRACE_HOOKS options KDTRACE_FRAME options MAC options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options COMPAT_FREEBSD32 options GEOM_LABEL options GEOM_RAID options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL options MD_ROOT options QUOTA options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options SCTP options TCP_OFFLOAD options INET6 options INET options PREEMPTION options SCHED_ULE options NEW_PCIB options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD device isa device mem device io device uart_ns8250 device cpufreq device acpi device pci device fdc device ahci device ata device mvs device siis device ahc device ahd device esp device hptiop device isp device mpt device mps device sym device trm device adv device adw device aic device bt device isci device scbus device ch device da device sa device cd device pass device ses device amr device arcmsr device ciss device dpt device hptmv device hptnr device hptrr device hpt27xx device iir device ips device mly device twa device tws device aac device aacp device aacraid device ida device mfi device mlx device twe device atkbdc device atkbd device psm device kbdmux device vga device splash device sc device agp device cbb device pccard device cardbus device uart device ppc device ppbus device lpt device plip device ppi device puc device bxe device de device em device igb device ixgbe device le device ti device txp device vx device miibus device ae device age device alc device ale device bce device bfe device bge device cas device dc device et device fxp device gem device hme device jme device lge device msk device nfe device nge device pcn device re device rl device sf device sge device sis device sk device ste device stge device tl device tx device vge device vr device wb device xl device cs device ed device ex device ep device fe device sn device xe device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_amrr device an device ath device ath_pci device ath_hal device ath_rate_sample device ipw device iwi device iwn device malo device mwl device ral device wi device wpi device loop device random device ether device vlan device tun device pty device md device gif device faith device firmware device bpf device uhci device ohci device ehci device xhci device usb device uhid device ukbd device ulpt device umass device ums device urio device u3g device uark device ubsa device uftdi device uipaq device uplcom device uslcom device uvisor device uvscom device aue device axe device cdce device cue device kue device rue device udav device rum device run device uath device upgt device ural device urtw device zyd device sound device snd_cmi device snd_csa device snd_emu10kx device snd_es137x device snd_hda device snd_ich device snd_uaudio device snd_via8233 device virtio device virtio_pci device vtnet device virtio_blk device virtio_scsi device virtio_balloon ------------------------------------------------------------------------ ddb capture buffer ddb: ddb_capture: kvm_nlist -- Marko Cupać From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 18:03:21 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 00C88511 for ; Tue, 27 Aug 2013 18:03:20 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7A3C92868 for ; Tue, 27 Aug 2013 18:03:20 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id y6so2853836lbh.21 for ; Tue, 27 Aug 2013 11:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=bMBjQLbF4lvHObuLc2TmMwm6WYSEeVQ7ZJazOpXQiEM=; b=s2DZXKAzTiTTQj8+d8zXWtaNAXCnPc5PEx1USC0eQn59H1CHQKIDljONIVJuDO2deq 2rG6Ew4GRHB5y1Vvg5yG6BBqNHRu3SGdGA0D+dNw/MTUGOt26AHyNOTpZFVR91FHjFRX 9Nde/80vWJKdiVxl1B1aU7fD6BqOhVDjGASU7mNOL7TNS89569AuIQShVOJbScdIRnU1 9fdiybY7Do15AnNsHPYpDGIMIrxM5T+S4bPJYDmEQ3KVXOqor+cpfgOIE+428k3htHHk T3HS47btJiNB3uy2OhezOq4cZm1yLoifjKe9PfsdQDRJyv8A+OVvGPCNjW5p2dVW6SSD 5arA== X-Received: by 10.112.146.33 with SMTP id sz1mr18145291lbb.14.1377626598402; Tue, 27 Aug 2013 11:03:18 -0700 (PDT) Received: from limbo.xim.bz (ratatosk.b1t.name. [46.150.100.6]) by mx.google.com with ESMTPSA id vx8sm7656642lbb.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 11:03:17 -0700 (PDT) Message-ID: <521CE9E4.2060305@gmail.com> Date: Tue, 27 Aug 2013 21:03:16 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: stable@freebsd.org Subject: can't build ^/releng/9.2 from ^/releng/9.1 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, 27 Aug 2013 18:03:21 -0000 Hi all. Just tried building 9.2 on one of my servers: ===> usr.bin/makewhatis (obj,depend,all,install) install -C -s -o root -g wheel -m 555 makewhatis /usr/obj/usr/src/tmp/legacy/usr/bin/makewhatis install -C -o root -g wheel -m 555 /usr/src/usr.bin/makewhatis/makewhatis.local.sh /usr/obj/usr/src/tmp/legacy/usr/libexec/makewhatis.local /usr/obj/usr/src/tmp/legacy/usr/libexec/catman.local -> /usr/obj/usr/src/tmp/legacy/usr/libexec/makewhatis.local install: illegal option -- l usage: install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode] [-o owner] file1 file2 install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode] [-o owner] file1 ... fileN directory install -d [-v] [-g group] [-m mode] [-o owner] directory ... *** [_installlinks] Error code 64 1 error *** [bootstrap-tools] Error code 2 1 error *** [_bootstrap-tools] Error code 2 1 error *** [buildworld] Error code 2 1 error I know I can build and install `install` by hand but this impales updating process a bit... -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 20:10:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B1D4DA66 for ; Tue, 27 Aug 2013 20:10:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 72E572F02 for ; Tue, 27 Aug 2013 20:09:59 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAG0HHVKDaFve/2dsb2JhbABZDgiDJlGDJ70BgTl0giQBAQEDAQEBASArIAsbDgoCAg0ZAikBCSYGCAcEARwEh1oGDKYzkiyBKYxyEA14NAeCaIExA5Umg3aQM4JhWyAyfAcXIg X-IronPort-AV: E=Sophos;i="4.89,970,1367985600"; d="scan'208";a="47717903" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 27 Aug 2013 16:09:47 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 5A4DCB404A; Tue, 27 Aug 2013 16:09:47 -0400 (EDT) Date: Tue, 27 Aug 2013 16:09:47 -0400 (EDT) From: Rick Macklem To: Daniel Braniss Message-ID: <161178921.14385682.1377634187359.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: another? NFS deadlock on 9.2-PRERELEASE MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) 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: Tue, 27 Aug 2013 20:10:00 -0000 Daniel Braniss wrote: > > Daniel Braniss wrote: > > > > Daniel Braniss wrote: > > > > > I upgraded our web server, and only after 3 hours it hung :-( > > > > > (as a side note, I have 2 other web servers, also running 9.2 > > > > > doing > > > > > great :-) > > > > > go figure. > > > > > > > > > > anyways, in > > > > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/0 > > > > > > > > > > is the info after a forced panic. > > > > > > > > > Looks like the same hang to me. Several threads are sleeping on > > > > "pgrbwt" > > > > and lots are waiting for an NFS vnode lock. > > > > > > > > It should be fixed in RC3 (or revert r250907). If it still > > > > hangs > > > > with > > > > RC3 (or r250907 reverted), email again. > > > > > > > im following stable, hence it's till calling itself > > > 9.2-PRERELEASE, > > > but > > > I did a sync this morning - local time, after rc3 was anounced. > > > but after 3.45 minutes is hung, data in > > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/1 > > > > > > I can't easely revert r250907, since i'm using mercuriall, but if > > > someone > > > can send me the pre r250907 files, i'll try. > > > The pre-r250907 version of uipc_syscalls is at: http://people.freebsd.org/~rmacklem/uipc_syscalls.c in case you want to try it. rick > > r254947, which was committed to stable/9 a few hours ago is > > believed to > > fix the problem. Please update your stable/9 to post-r254947 and > > try it. > > > the current kernel has that fix (sys/kern/uipc_syscalls.c) > and if you check the core.txt/1 you will see no pgrbwt, only newnsf > ... > > danny > > > rick > > > > > thanks, > > > danny > > > > > > > rick > > > > > > > > > my guts say its running out of resources - mainly network > > > > > related, > > > > > but > > > > > can't pinpoint it. > > > > > > > > > > any help will be most welcomed > > > > > > > > > > cheers, > > > > > danny > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > freebsd-stable@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > > To unsubscribe, send any mail to > > > "freebsd-stable-unsubscribe@freebsd.org" > > > > > > From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 21:02:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AB8207DD for ; Tue, 27 Aug 2013 21:02:20 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2DFD92210 for ; Tue, 27 Aug 2013 21:02:20 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id y10so1026288wgg.15 for ; Tue, 27 Aug 2013 14:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=La6fAsEIMumvSUIKViW4RazuJDn72ebCVLv5RDGKMs8=; b=Q7dBLy4UWOwyPHmOL8Au5aKgIE85xe0sT0+fYO9cZk+lO/TgOyEFmQRSeyiL97JNUP ctAjF5yArO/QoNgOKbUcfLgSoGcg2L0CIqe8BFghr8bwE1qQJaIyMwJBiW3s3JvuY9og j2kgP2dYon0IdP43kogRpOQewd9FraLCPNnaAy9S6RUztwKUkeJRhpzwb8D1ZNTPXWdN cOIiCCmxa9jsSPIb31OzeTs5PktzKN3BpQdzzB+kfHnhGg5BzfHKwQWFq9WCuaNkQTS/ Or0O3AT3xcUWNixKuYD1q2kH5GKMCGdOqNUQq+Dc9fCV8CTH7k6qP4ENndqufdo9e0qj n6Sw== X-Received: by 10.180.187.175 with SMTP id ft15mr13058561wic.20.1377637338438; Tue, 27 Aug 2013 14:02:18 -0700 (PDT) Received: from [192.168.1.15] (5ED0E470.cm-7-1d.dynamic.ziggo.nl. [94.208.228.112]) by mx.google.com with ESMTPSA id a8sm273483wie.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 14:02:17 -0700 (PDT) Message-ID: <521D13D7.4000808@gmail.com> Date: Tue, 27 Aug 2013 23:02:15 +0200 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Alex V. Petrov" Subject: Re: make buildworld fails 9.2 PRERELEASE to RC3 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.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: Tue, 27 Aug 2013 21:02:20 -0000 Alex V. Petrov wrote: > before 'make buildworld' > need: > cd /usr/src/usr.bin/yacc && make obj && make depend && make && make > install > > > 2013/8/27 Johan Hendriks > > > Hello all > > I am running the following version of FreeBSD > > uname -a > FreeBSD beasty.testdomain.local 9.2-PRERELEASE FreeBSD > 9.2-PRERELEASE #0 > r254646: Thu Aug 22 09:46:05 CEST 2013 > root@beasty.testdomain.local:/usr/obj/usr/src/sys/KRNL > amd64 > > I have updated the source using the following command. > > svn co http://svn.freebsd.org/base/releng/9.2 /usr/src > Checked out revision 254955. > > But when i do a buildworld it errors out. > > > cc -O2 -pipe -march=core2 -DDES -std=gnu99 -fstack-protector > -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > -Wno-unused-parameter > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter > -Wcast-align -Wchar-subscripts -Winline -Wnested-externs > -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -c /usr/src/bin/ed/undo.c > cc -O2 -pipe -march=core2 -DDES -std=gnu99 -fstack-protector > -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > -Wno-unused-parameter > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter > -Wcast-align -Wchar-subscripts -Winline -Wnested-externs > -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -o ed buf.o cbc.o glbl.o > io.o > main.o re.o sub.o undo.o -lcrypto > gzip -cn /usr/src/bin/ed/ed.1 > ed.1.gz > ===> bin/expr (all) > cc -O2 -pipe -march=core2 -std=gnu99 -fstack-protector > -Wsystem-headers > -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual > -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -c expr.c > cc1: warnings being treated as errors > expr.c:812: warning: redundant redeclaration of 'yyparse' > /usr/src/bin/expr/expr.y:77: warning: previous declaration of > 'yyparse' was > here > *** [expr.o] Error code 1 > > Stop in /usr/src/bin/expr. > *** [all] Error code 1 > > Stop in /usr/src/bin. > *** [bin.all__D] Error code 1 > > Stop in /usr/src. > *** [everything] Error code 1 > > Stop in /usr/src. > *** [buildworld] Error code 1 > > Stop in /usr/src. > > I deleted /usr/obj/* > I deleted /usr/src and did a new svn checkout. > > But the errors keeps coming. > > Is there anything i can do ! > > > regards > Johan > _______________________________________________ > 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 > " > > Thanks, i will try tomorrow when back in the office.. regards Johan From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 22:16:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8FD49372 for ; Tue, 27 Aug 2013 22:16:05 +0000 (UTC) (envelope-from Robert.Burmeister@utoledo.edu) Received: from smtpin2.utoledo.edu (smtpin2.utoledo.edu [131.183.2.214]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 19FD7271E for ; Tue, 27 Aug 2013 22:16:04 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsAAIYkHVKDtwN/l2dsb2JhbABZgzxRwCmBIxYOAQEBAQEIFgc8giQBAQU4GyYQBQYOCgkWDwkDAgECAUUGDQEFAgEBh30Mr3CIbwSPZAeEGQOIeZUgjnKCDg X-IronPort-AV: E=Sophos;i="4.89,970,1367985600"; d="scan'208";a="231418971" Received: from dlpint01.utoledo.edu ([131.183.3.127]) by smtpin2.utoledo.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Aug 2013 18:16:03 -0400 Received: from MsgApp11.utad.utoledo.edu (msgapp11.utad.utoledo.edu [131.183.3.7]) by dlpint01.utoledo.edu (RSA Interceptor); Tue, 27 Aug 2013 18:15:50 -0400 Received: from [192.168.1.65] (76.238.196.183) by Email.Utoledo.Edu (131.183.3.18) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 27 Aug 2013 18:15:49 -0400 Message-ID: <521D24F4.4060609@UToledo.edu> Date: Tue, 27 Aug 2013 18:15:16 -0400 From: Robert Burmeister User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Sergey Kandaurov Subject: Re: Suggest changing dirhash defaults for FreeBSD 9.2. X-Priority: 1 (Highest) References: <521C9E85.4060801@UToledo.edu> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [76.238.196.183] X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow 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: Tue, 27 Aug 2013 22:16:05 -0000 On 8/27/2013 9:40 AM, Sergey Kandaurov wrote: > On 27 August 2013 16:41, Robert Burmeister > wrote: >> I have been experimenting with dirhash settings, and have scoured the internet for other peoples' experience with it. >> (I found the performance improvement in compiling has forestalled the need to add an SSD drive. ;-) >> >> I believe that increasing the following values by 10 would benefit most FreeBSD users without disadvantage. >> >> vfs.ufs.dirhash_maxmem: 2097152 to 20971520 >> >> vfs.ufs.dirhash_reclaimage: 5 to 50 or 60 > vfs.ufs.dirhash_maxmem is further autotuned based on available physical memory. > See r214359 for details. > Sorry, the documentation has not been updated since 2008. https://wiki.freebsd.org/DirhashDynamicMemory What about bumping up vfs.ufs.dirhash_reclaimage > all hashes older than 5 seconds (tunable via a sysctl, > vfs.ufs.dirhash_reclaimage) will always be deleted when a vm_lowmem event > occurs, and if that doesn't free up at least 10% of the memory currently being > used by dirhash, more hashes will be destroyed from the head of the TAILQ > until we do free up at least 10% of the memory initially used. As the memory scavenger will keep nibbling until at least 10% of the cache is free, eradicating all entries older than 5 seconds for the first chop seems overly aggressive. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 27 23:01:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B3B3CF04; Tue, 27 Aug 2013 23:01:55 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F69B29B0; Tue, 27 Aug 2013 23:01:55 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id g12so6655685oah.20 for ; Tue, 27 Aug 2013 16:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RfgC2KV0LKMGCVG6JqSomKnmu2YcHd1ug1xbQphfBjY=; b=xJ0oGELqGdexP4uTM3emTdeYm+EXwJyyj4/95xnkQxfitwBarRMCsLgWzVAl2JROJf aqq/O9XlLJg6aa6s1VD1byk/TQuE5diMpaOLcWjogvY7VushArV000eW4G2MvSA6x+5Q srL2syEeoNCn8xp15lQOYLxEaWbP0+Zc9BYO1kXf//IpkQJ1z9Hg7XzlTnAtJze1CBOa E+vjfaPQaPvnYTFdp40WLCEpxCFeAbHgsAxGWxE5DnyT2gYp8qUecVju2Vd4XZKCiK0G 7xSrWsmu4CSX9JCjMS9r/uekCsdiMGTu5WvYsZSwdzec+UQgKMfeu0l3e/Pax9smHGHw kilw== MIME-Version: 1.0 X-Received: by 10.182.71.37 with SMTP id r5mr4140311obu.22.1377644514789; Tue, 27 Aug 2013 16:01:54 -0700 (PDT) Received: by 10.76.2.110 with HTTP; Tue, 27 Aug 2013 16:01:54 -0700 (PDT) In-Reply-To: <20130825141942.GB19969@lonrach.local> References: <20130822202027.GH94127@funkthat.com> <20130823151615.GD41379@roberto02-aw.erc.corp.eurocontrol.int> <20130823180413.GL94127@funkthat.com> <20130823182752.GA15392@lonrach.local> <20130825141942.GB19969@lonrach.local> Date: Tue, 27 Aug 2013 19:01:54 -0400 Message-ID: Subject: Re: patch to improve AES-NI performance From: Outback Dingo To: Ollivier Robert Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 23:01:55 -0000 On Sun, Aug 25, 2013 at 10:19 AM, Ollivier Robert wrote: > According to Ollivier Robert: > > You are right, I wanted to say r226837 which is the "code" one. > > FYI I've finally merged r226837,r226839 as r254856 in stable/9 as it is a > prerequesite to apply jmg's patch. I've asked re@ whether they would > consider this for 9.2. It is very late in the 9.2 release circle but that > patch has been in 10 for more than a year now... > > So this patch can now be applied to STABLE/9 for testing on a local system since these 3 revisions are now in?? > -- > Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- > roberto@keltia.freenix.fr > In memoriam to Ondine : http://ondine.keltia.net/ > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Aug 28 01:26: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DDAC8F1D; Wed, 28 Aug 2013 01:26:33 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9AD0A20A6; Wed, 28 Aug 2013 01:26:33 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7S1QWu8001162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 18:26:32 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7S1QWCn001161; Tue, 27 Aug 2013 18:26:32 -0700 (PDT) (envelope-from jmg) Date: Tue, 27 Aug 2013 18:26:32 -0700 From: John-Mark Gurney To: Outback Dingo Subject: Re: patch to improve AES-NI performance Message-ID: <20130828012632.GQ29777@funkthat.com> Mail-Followup-To: Outback Dingo , Ollivier Robert , freebsd-current@freebsd.org, freebsd-stable@freebsd.org References: <20130822202027.GH94127@funkthat.com> <20130823151615.GD41379@roberto02-aw.erc.corp.eurocontrol.int> <20130823180413.GL94127@funkthat.com> <20130823182752.GA15392@lonrach.local> <20130825141942.GB19969@lonrach.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 27 Aug 2013 18:26:32 -0700 (PDT) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 01:26:33 -0000 Outback Dingo wrote this message on Tue, Aug 27, 2013 at 19:01 -0400: > On Sun, Aug 25, 2013 at 10:19 AM, Ollivier Robert > wrote: > > > According to Ollivier Robert: > > > You are right, I wanted to say r226837 which is the "code" one. > > > > FYI I've finally merged r226837,r226839 as r254856 in stable/9 as it is a > > prerequesite to apply jmg's patch. I've asked re@ whether they would > > consider this for 9.2. It is very late in the 9.2 release circle but that > > patch has been in 10 for more than a year now... > > > > > So this patch can now be applied to STABLE/9 for testing on a local system > since these 3 revisions are now in?? I've compile tested the patch, but not run tested it: https://people.freebsd.org/~jmg/aesni.9stable.patch Note that 9stable uses gcc by default and this patch required clang, so make sure you set WITH_CLANG=YES WITH_CLANG_IS_CC=YES, otherwise it won't compile... This patch only required minor changes from my original patch to apply.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-stable@FreeBSD.ORG Wed Aug 28 04:00:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CB7331BC for ; Wed, 28 Aug 2013 04:00:11 +0000 (UTC) (envelope-from Robert.Burmeister@utoledo.edu) Received: from smtpin1.utoledo.edu (smtpin1.utoledo.edu [131.183.2.213]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 561FE271F for ; Wed, 28 Aug 2013 04:00:10 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsAAKJ0HVKDtwIWl2dsb2JhbABahA3AKYEkFg4BAQEBAQgWBzyCJAEBBTgbJhALDgoJFg8JAwIBAgFFBg0BBQIBAYd9r2aJE49kB4QZA4h5lSCOcoIO X-IronPort-AV: E=Sophos;i="4.89,973,1367985600"; d="scan'208";a="281503879" Received: from dlpint00.utoledo.edu ([131.183.2.22]) by smtpin1.utoledo.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Aug 2013 23:58:59 -0400 Received: from MsgApp11.utad.utoledo.edu (msgapp11.utad.utoledo.edu [131.183.3.7]) by dlpint00.utoledo.edu (RSA Interceptor); Tue, 27 Aug 2013 23:58:44 -0400 Received: from [192.168.1.65] (76.238.196.183) by Email.Utoledo.Edu (131.183.3.18) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 27 Aug 2013 23:58:43 -0400 Message-ID: <521D7552.5080008@UToledo.edu> Date: Tue, 27 Aug 2013 23:58:10 -0400 From: Robert Burmeister User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Sergey Kandaurov Subject: Re: Suggest changing dirhash defaults for FreeBSD 9.2. References: <521C9E85.4060801@UToledo.edu> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [76.238.196.183] X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow 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, 28 Aug 2013 04:00:11 -0000 On 8/27/2013 9:40 AM, Sergey Kandaurov wrote: > On 27 August 2013 16:41, Robert Burmeister > wrote: >> I have been experimenting with dirhash settings, and have scoured the internet for other peoples' experience with it. >> (I found the performance improvement in compiling has forestalled the need to add an SSD drive. ;-) >> >> I believe that increasing the following values by 10 would benefit most FreeBSD users without disadvantage. >> >> vfs.ufs.dirhash_maxmem: 2097152 to 20971520 >> >> vfs.ufs.dirhash_reclaimage: 5 to 50 or 60 > vfs.ufs.dirhash_maxmem is further autotuned based on available physical memory. > See r214359 for details. > [Spock Eyebrow of Thought] I'm running FreeBSD i386 9.2, that allows a max of 4 Gigs of RAM. I think the algorithm is still overly conservative for 32 bit systems, which are more likely to be using UFS. As 64 bit platforms tend to have more RAM and use ZFS, is the same tuning algorithm appropriate for both? From owner-freebsd-stable@FreeBSD.ORG Wed Aug 28 05:17:41 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 075011C9 for ; Wed, 28 Aug 2013 05:17:41 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C0D362A99 for ; Wed, 28 Aug 2013 05:17:40 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id k14so7743526iea.5 for ; Tue, 27 Aug 2013 22:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=4CzQFPAmZ7D81wRO3HiR7E3+dJJ5lxgibjeVZP16M/o=; b=PgDxgB9swHNvrarBTffOx522KB4tQuwxFOozIRVeMplEvfwVi9qLVc4fmyF4TAkuuF q05Nc04WIJaEjPZNJY5VpC4c1Calk7uZ6newWg8C5poQmQ34NnW9umyQ3fTM9AG5fkew /11ck4ZXbmurFmveZ9zPvi0fsjjz3oIzYTCeM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=4CzQFPAmZ7D81wRO3HiR7E3+dJJ5lxgibjeVZP16M/o=; b=DbRtGSSOYbY+JB6JdFa48MCceWqMzQWDborSb6zByKvYCyIaf2reXAmvxmJ5JyK1Lb iEwX9C7j66R4bJ5Rt2NME2ZOuMv2DQGqr5fYNdLY4048QMGW5K1EmlYy+/JXCiYNZNWq CZXKS05yOa9Kpa7IUTPX+ujp9O1AOMRVJNduv9j46irp/xbVL7rggX+XQRmJkRy8Cp5l uZXqRQE7ZRshCoU6qppFUvJ0WULL/ZyxS9Zt2+kdfpiFS9SIquiEV2hy/xNdGY2tQKyr jgWxmVMelL/Bf/oUBlpWDo4hyoCtXDEGF4Fx7XVS9XgeuGpwRsZJZ7WcRej80uWThFLA vLBQ== X-Gm-Message-State: ALoCoQlzBK0RMIcdAploh2WXpRlrFW7Ldi2bCY10imwLjpKzMMNil7EP0xNUN625TQaxALc859OB X-Received: by 10.42.104.198 with SMTP id s6mr440304ico.20.1377667060175; Tue, 27 Aug 2013 22:17:40 -0700 (PDT) Received: from [192.168.30.2] (75-128-120-29.dhcp.aldl.mi.charter.com. [75.128.120.29]) by mx.google.com with ESMTPSA id p5sm2272827igj.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Aug 2013 22:17:38 -0700 (PDT) Subject: 9-STABLE amd64 / VirtualBox Testcases From: Jason Hellenthal Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5CA33FD5-614E-48B0-981A-1815F4EF312A; protocol="application/pkcs7-signature" X-Mailer: iPhone Mail (11A4449d) Message-Id: <23B43405-0802-4C10-A8C9-185ED38436A5@dataix.net> Date: Wed, 28 Aug 2013 01:17:35 -0400 To: "[FreeBSD Stable]" , "virtualization@freebsd.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) 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, 28 Aug 2013 05:17:41 -0000 --Apple-Mail-5CA33FD5-614E-48B0-981A-1815F4EF312A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Is anyone else seeing the build of VB on 9 failing on the test cases ? With t= wo files that cannot be deleted and and one that after touching the two file= s so they can that errors out because of a parenthesis syntax error ? Don't have the exact names of these off hand due to no inbound outbound conn= ection to the machine but in particular it seems to only be a problem with t= he test cases at this point and would like to find a way to just disable the= build of them for right now as I'm just trying to wrap this project up. These are builds from all recent sources and ports as of today. I see some variables within the vbox ose that just echoes the null car into l= ocalconfig.kmk but nothing obvious as of yet to completely wipe it from the b= uild cycle. Please keep me CCd upon reply I don't believe I am on the virt list as of ye= t. Thanks --=20 Jason Hellenthal Inbox: jhellenthal@Gmail.com Voice: +1 (616) 953-0176 JJH48-ARIN --=20 Jason Hellenthal Inbox: jhellenthal@DataIX.net Voice: +1 (616) 953-0176 JJH48-ARIN --Apple-Mail-5CA33FD5-614E-48B0-981A-1815F4EF312A Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgyODA1MTczN1owIwYJKoZIhvcN AQkEMRYEFPp6jnjmdUES9B+HZlms3IPXxbyZMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAoAglTG2GdTZPFKcIBv2t cQ3II48T8/0svthif7ZoiJCsh5zZyYPl8/XIfWNAgnkKTqsUkAO0dsNcI6uJt+SHazKQpfgzTLbG 2e86L1mn07icWND2hA+PrcO9ibmiMQcT3y7V8IX3qiCTsokQU/cc7wGP6rElplInXYNTHGBuMFZh rchVFchtKY3lyDnOBoVPbtvy2jaicFuZ440+hCSl5KRyql/ulup8cIiwjD0g5Ns3lli4kjPcHsR6 mcMecYCdRY86xjRQviifLjv0v7sZzOALiTmAtDRxI4eM1n7l3Vq1uEPrij3TEdRFcY374apslmt1 QMK9O/sJ20qe2N2iSQAAAAAAAA== --Apple-Mail-5CA33FD5-614E-48B0-981A-1815F4EF312A-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 28 06:20:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C5A4F469 for ; Wed, 28 Aug 2013 06:20: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]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 78B752D7F for ; Wed, 28 Aug 2013 06:20:30 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1VEZ78-0002PT-If; Wed, 28 Aug 2013 09:20:22 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Rick Macklem Subject: Re: another? NFS deadlock on 9.2-PRERELEASE In-reply-to: <161178921.14385682.1377634187359.JavaMail.root@uoguelph.ca> References: <161178921.14385682.1377634187359.JavaMail.root@uoguelph.ca> Comments: In-reply-to Rick Macklem message dated "Tue, 27 Aug 2013 16:09:47 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Aug 2013 09:20:22 +0300 From: Daniel Braniss Message-ID: 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, 28 Aug 2013 06:20:30 -0000 > Daniel Braniss wrote: > > > Daniel Braniss wrote: > > > > > Daniel Braniss wrote: > > > > > > I upgraded our web server, and only after 3 hours it hung :-( > > > > > > (as a side note, I have 2 other web servers, also running 9.2 > > > > > > doing > > > > > > great :-) > > > > > > go figure. > > > > > > > > > > > > anyways, in > > > > > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/0 > > > > > > > > > > > > is the info after a forced panic. > > > > > > > > > > > Looks like the same hang to me. Several threads are sleeping on > > > > > "pgrbwt" > > > > > and lots are waiting for an NFS vnode lock. > > > > > > > > > > It should be fixed in RC3 (or revert r250907). If it still > > > > > hangs > > > > > with > > > > > RC3 (or r250907 reverted), email again. > > > > > > > > > im following stable, hence it's till calling itself > > > > 9.2-PRERELEASE, > > > > but > > > > I did a sync this morning - local time, after rc3 was anounced. > > > > but after 3.45 minutes is hung, data in > > > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/core.txt/1 > > > > > > > > I can't easely revert r250907, since i'm using mercuriall, but if > > > > someone > > > > can send me the pre r250907 files, i'll try. > > > > > The pre-r250907 version of uipc_syscalls is at: > http://people.freebsd.org/~rmacklem/uipc_syscalls.c > in case you want to try it. > thanks, I think I have a kernel pre r250907. In the meantime I did 2 things: 1- made the /(root) local - as opposed to nfs'ed 2- have a watchdog to reboot in case of hang the host has been up for more than 14hs ( i doubt it's because of 2 -) lets see how things develope thanks, danny > rick > > > > r254947, which was committed to stable/9 a few hours ago is > > > believed to > > > fix the problem. Please update your stable/9 to post-r254947 and > > > try it. > > > > > the current kernel has that fix (sys/kern/uipc_syscalls.c) > > and if you check the core.txt/1 you will see no pgrbwt, only newnsf > > ... > > > > danny > > > > > rick > > > > > > > thanks, > > > > danny > > > > > > > > > rick > > > > > > > > > > > my guts say its running out of resources - mainly network > > > > > > related, > > > > > > but > > > > > > can't pinpoint it. > > > > > > > > > > > > any help will be most welcomed > > > > > > > > > > > > cheers, > > > > > > danny > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > freebsd-stable@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > > > To unsubscribe, send any mail to > > > > "freebsd-stable-unsubscribe@freebsd.org" > > > > > > > > > > From owner-freebsd-stable@FreeBSD.ORG Wed Aug 28 09:49:06 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3759877D for ; Wed, 28 Aug 2013 09:49:06 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BC56A29A8 for ; Wed, 28 Aug 2013 09:49:05 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VEcMy-0000KV-Gg for freebsd-stable@freebsd.org; Wed, 28 Aug 2013 11:48:56 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Aug 2013 11:48:56 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Aug 2013 11:48:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Subject: Re: Suggest changing dirhash defaults for FreeBSD 9.2. Date: Wed, 28 Aug 2013 11:48:43 +0200 Lines: 65 Message-ID: References: <521C9E85.4060801@UToledo.edu> <521D7552.5080008@UToledo.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2TFUBVIQGHKUAUIOTNOCI" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130322 Thunderbird/17.0.4 In-Reply-To: <521D7552.5080008@UToledo.edu> X-Enigmail-Version: 1.5.1 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, 28 Aug 2013 09:49:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2TFUBVIQGHKUAUIOTNOCI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 28/08/2013 05:58, Robert Burmeister wrote: >=20 > On 8/27/2013 9:40 AM, Sergey Kandaurov wrote: >> On 27 August 2013 16:41, Robert Burmeister >> wrote: >>> I have been experimenting with dirhash settings, and have scoured the= >>> internet for other peoples' experience with it. >>> (I found the performance improvement in compiling has forestalled the= >>> need to add an SSD drive. ;-) >>> >>> I believe that increasing the following values by 10 would benefit >>> most FreeBSD users without disadvantage. >>> >>> vfs.ufs.dirhash_maxmem: 2097152 to 20971520 >>> >>> vfs.ufs.dirhash_reclaimage: 5 to 50 or 60 >> vfs.ufs.dirhash_maxmem is further autotuned based on available >> physical memory. >> See r214359 for details. >> > [Spock Eyebrow of Thought] >=20 > I'm running FreeBSD i386 9.2, that allows a max of 4 Gigs of RAM. To what value does the algorithm tune in your case? On my 16 GB machine, it's ~~ 25 MB: vfs.ufs.dirhash_maxmem: 26968064 > I think the algorithm is still overly conservative for 32 bit systems, > which are more likely to be using UFS. >=20 > As 64 bit platforms tend to have more RAM and use ZFS, > is the same tuning algorithm appropriate for both? The policy is to use fractions of the installed RAM (though in a roundabout way), so it should scale reasonably well to both systems with large and small memories. I'll bump vfs.ufs.dirhash_reclaimage to 60, it's worth it. ------enig2TFUBVIQGHKUAUIOTNOCI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIdx3sACgkQ/QjVBj3/HSwqAwCfYUa6VKsM+xKlyx9DIxKjjDPT u/cAnRYdBxuUFsY/yj3DBPw62mdOmBl5 =MuBK -----END PGP SIGNATURE----- ------enig2TFUBVIQGHKUAUIOTNOCI-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 28 11:07:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5C53337F for ; Wed, 28 Aug 2013 11:07:33 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C899D2E34 for ; Wed, 28 Aug 2013 11:07:32 +0000 (UTC) Received: by mail-bk0-f42.google.com with SMTP id my10so2174754bkb.1 for ; Wed, 28 Aug 2013 04:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=b/eNOlGw/HuOYSQ7gyU9deF1S71ciJ3VmeXIvykqI24=; b=veFNiACy6ERdEeoU95LZdcp/CXuW/m7jL1lkNVZ28h0mTZqyrByj9Sc6Yg6YQtt+RM yLTILvzazweXLSWCj6cF4+vpVy+O93F8swaRFQq3aosDpL0508dCVDpTI9OxXu/oHLTN EkVhOmowT6xkPZHmtrye79UbYnAXXWKZ2J4dvNCVIc/CT3bxn7FrNnqbi9HF2OwuOGli YBZFk0H1wgC1ij3sU92lmS7YlyeZIDkNMC5c3Iu31ANXh19Da46hbL3auwFZFllQ/9MP J8QDxVvTOtnOgaxIrvMfzc/XOONAxXSi8ZYiVkyJ31Y4aTEMTSN+Stm07WqnlFzlzIov voXg== X-Received: by 10.205.15.72 with SMTP id pt8mr18820321bkb.17.1377688050923; Wed, 28 Aug 2013 04:07:30 -0700 (PDT) Received: from [192.168.1.129] ([193.173.55.180]) by mx.google.com with ESMTPSA id jt14sm5746252bkb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 04:07:30 -0700 (PDT) Message-ID: <521DD9F1.2050504@gmail.com> Date: Wed, 28 Aug 2013 13:07:29 +0200 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-stable Subject: Re: make buildworld fails 9.2 PRERELEASE to RC3 References: <521D13D7.4000808@gmail.com> In-Reply-To: <521D13D7.4000808@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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, 28 Aug 2013 11:07:33 -0000 Johan Hendriks wrote: > Alex V. Petrov wrote: >> before 'make buildworld' >> need: >> cd /usr/src/usr.bin/yacc && make obj && make depend && make && make >> install >> >> >> 2013/8/27 Johan Hendriks > > >> >> Hello all >> >> I am running the following version of FreeBSD >> >> uname -a >> FreeBSD beasty.testdomain.local 9.2-PRERELEASE FreeBSD >> 9.2-PRERELEASE #0 >> r254646: Thu Aug 22 09:46:05 CEST 2013 >> root@beasty.testdomain.local:/usr/obj/usr/src/sys/KRNL >> amd64 >> >> I have updated the source using the following command. >> >> svn co http://svn.freebsd.org/base/releng/9.2 /usr/src >> Checked out revision 254955. >> >> But when i do a buildworld it errors out. >> >> >> cc -O2 -pipe -march=core2 -DDES -std=gnu99 -fstack-protector >> -Wsystem-headers -Werror -Wall -Wno-format-y2k -W >> -Wno-unused-parameter >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith >> -Wreturn-type >> -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter >> -Wcast-align -Wchar-subscripts -Winline -Wnested-externs >> -Wredundant-decls >> -Wold-style-definition -Wno-pointer-sign -c /usr/src/bin/ed/undo.c >> cc -O2 -pipe -march=core2 -DDES -std=gnu99 -fstack-protector >> -Wsystem-headers -Werror -Wall -Wno-format-y2k -W >> -Wno-unused-parameter >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith >> -Wreturn-type >> -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter >> -Wcast-align -Wchar-subscripts -Winline -Wnested-externs >> -Wredundant-decls >> -Wold-style-definition -Wno-pointer-sign -o ed buf.o cbc.o >> glbl.o io.o >> main.o re.o sub.o undo.o -lcrypto >> gzip -cn /usr/src/bin/ed/ed.1 > ed.1.gz >> ===> bin/expr (all) >> cc -O2 -pipe -march=core2 -std=gnu99 -fstack-protector >> -Wsystem-headers >> -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter >> -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual >> -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align >> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >> -Wold-style-definition -Wno-pointer-sign -c expr.c >> cc1: warnings being treated as errors >> expr.c:812: warning: redundant redeclaration of 'yyparse' >> /usr/src/bin/expr/expr.y:77: warning: previous declaration of >> 'yyparse' was >> here >> *** [expr.o] Error code 1 >> >> Stop in /usr/src/bin/expr. >> *** [all] Error code 1 >> >> Stop in /usr/src/bin. >> *** [bin.all__D] Error code 1 >> >> Stop in /usr/src. >> *** [everything] Error code 1 >> >> Stop in /usr/src. >> *** [buildworld] Error code 1 >> >> Stop in /usr/src. >> >> I deleted /usr/obj/* >> I deleted /usr/src and did a new svn checkout. >> >> But the errors keeps coming. >> >> Is there anything i can do ! >> >> >> regards >> Johan >> _______________________________________________ >> 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 >> " >> >> > Thanks, i will try tomorrow when back in the office.. > regards > Johan That did the trick! Thank you. regards Johan From owner-freebsd-stable@FreeBSD.ORG Wed Aug 28 13:10: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 899D3BAD; Wed, 28 Aug 2013 13:10:40 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1478F2617; Wed, 28 Aug 2013 13:10:39 +0000 (UTC) Received: from juno.lyxys.ka.sub.org (juno.lyx [IPv6:fd2a:89ca:7d54:0:20f:feff:fe0e:7312]) by saturn.lyxys.ka.sub.org (8.14.7/8.14.7) with ESMTP id r7SDAHaI005041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Aug 2013 15:10:18 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.14.7/8.14.7) with ESMTP id r7SDAHlT089712; Wed, 28 Aug 2013 15:10:17 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.14.7/8.14.7/Submit) id r7SDAH94089709; Wed, 28 Aug 2013 15:10:17 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyxys.ka.sub.org: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Wed, 28 Aug 2013 15:10:17 +0200 From: Wolfgang Zenker To: freebsd-stable@freebsd.org, freebsd-i18n@freebsd.org Subject: State of Unicode collation support in FreeBSD? Message-ID: <20130828131017.GA89499@lyxys.ka.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: private site User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (saturn.lyxys.ka.sub.org [IPv6:fd2a:89ca:7d54:1:200:24ff:feca:b4cc]); Wed, 28 Aug 2013 15:10:18 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 13:10:40 -0000 [crossposted to -stable and -i18n, replies directed to -stable] Hi everyone, could someone point me to infos regarding Unicode collation support in FreeBSD? All I could find was https://wiki.freebsd.org/KonradJankowski/Collation but that page has not been changed in more than two years. Looking at sources of -current it doesn't look like those changes made it into the source tree yet. Wolfgang From owner-freebsd-stable@FreeBSD.ORG Wed Aug 28 13:27:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 977FC127 for ; Wed, 28 Aug 2013 13:27:50 +0000 (UTC) (envelope-from lattera@gmail.com) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5754B272B for ; Wed, 28 Aug 2013 13:27:50 +0000 (UTC) Received: by mail-ve0-f180.google.com with SMTP id pb11so4059128veb.39 for ; Wed, 28 Aug 2013 06:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=t+YfL5AadCIW9xSy8PuMwnsd2kvHOKOq3BOt2VGN6YM=; b=q6Af+R9ZXUkbwvRS+bOGYvAw4ExOAiejYZoIhlH89ESITMeaUhHw3z6QosrfUpT03A y0FVHfXLK0tkSQ8E9JDnNVr3PWrrcniLuiCrnruUskj916+QG1sKHvQWLeLW9MBkWIy4 /R++oU9/yEYVqR9+QGAcpkNRkv62VtBiAx6XCFksdza/A/02gPycgTXABH4xs7kELq21 pLWF4W/H+uj5p+wvjhT4jaqVsDEoHndsnVP/oKPUiRtwonoBBPmXQ4m4HSJy2ydGxcos eg5B3j91HA5LoqF+AyKXzw3L6IyznAxMEwo7Fs/RUgcLVNp82bkC7wHa7aKy8+Om1pJL d97w== MIME-Version: 1.0 X-Received: by 10.52.117.68 with SMTP id kc4mr20098333vdb.0.1377696469426; Wed, 28 Aug 2013 06:27:49 -0700 (PDT) Received: by 10.58.168.132 with HTTP; Wed, 28 Aug 2013 06:27:49 -0700 (PDT) In-Reply-To: <20130827164125.e5cac3824c79c8fffb2fd319@mimar.rs> References: <20130827125800.79c2f1949236949be6459c41@mimar.rs> <20130827164125.e5cac3824c79c8fffb2fd319@mimar.rs> Date: Wed, 28 Aug 2013 09:27:49 -0400 Message-ID: Subject: Re: virtualbox crashes r254557 From: Shawn Webb To: =?UTF-8?B?TWFya28gQ3VwYcSH?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: David Demelier , "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, 28 Aug 2013 13:27:50 -0000 On Tue, Aug 27, 2013 at 10:41 AM, Marko Cupa=C4=87 w= rote: > On Tue, 27 Aug 2013 15:59:19 +0200 > David Demelier wrote: > >> Yes you can paste the dump here > > kaa.mimar.rs dumped core - see /var/crash/vmcore.1 > > Tue Aug 27 12:34:13 CEST 2013 > > FreeBSD kaa.mimar.rs 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254557: Su= n Aug 25 22:44:52 CEST 2013 pacija@kaa.mimar.rs:/usr/obj/usr/src/sys/KA= AGEN amd64 > > panic: page fault > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 2; apic id =3D 02 > fault virtual address =3D 0x0 > fault code =3D supervisor read instruction, page not present > instruction pointer =3D 0x20:0x0 > stack pointer =3D 0x28:0xffffff8127951580 > frame pointer =3D 0x28:0xffffff81279515b0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 1929 (VirtualBox) > trap number =3D 12 > panic: page fault > cpuid =3D 2 > KDB: stack backtrace: > #0 0xffffffff80948356 at kdb_backtrace+0x66 > #1 0xffffffff8090deae at panic+0x1ce > #2 0xffffffff80cf2c00 at trap_fatal+0x290 > #3 0xffffffff80cf2f61 at trap_pfault+0x211 > #4 0xffffffff80cf3514 at trap+0x344 > #5 0xffffffff80cdc843 at calltrap+0x8 > #6 0xffffffff8285cd5e at vboxNetFltPortOsXmit+0xee > #7 0xffffffff8285dcb4 at vboxNetFltPortXmit+0x64 > #8 0xffffffff828c83f8 at fuse_germ_vnops+0x55cf8 > #9 0xffffffff828ca182 at fuse_germ_vnops+0x57a82 > #10 0xffffffff828caf12 at fuse_germ_vnops+0x58812 > #11 0xffffffff82889647 at fuse_germ_vnops+0x16f47 > #12 0xffffffff828898a8 at fuse_germ_vnops+0x171a8 > #13 0xffffffff825963b2 at supdrvIOCtl+0x1d12 > #14 0xffffffff8259bef0 at VBoxDrvFreeBSDIOCtl+0x1d0 > #15 0xffffffff807f4cbb at devfs_ioctl_f+0x7b > #16 0xffffffff8095ae16 at kern_ioctl+0x106 > #17 0xffffffff8095b05d at sys_ioctl+0xfd > Uptime: 3h19m29s > Dumping 734 out of 3984 MB:..3%..11%..22%..31%..42%..51%..61%..72%..81%..= 92% > It appears I'm having the same issue and at least one other (who I talked to on IRC) is having the same issue on 10-CURRENT. Should I revert my box to an older 9-STABLE commit? Has a PR been filed? From owner-freebsd-stable@FreeBSD.ORG Wed Aug 28 14:20:34 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 22C9D342 for ; Wed, 28 Aug 2013 14:20:34 +0000 (UTC) (envelope-from trtrmitya@gmail.com) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9DB3B2A5B for ; Wed, 28 Aug 2013 14:20:33 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id ev20so4843825lab.11 for ; Wed, 28 Aug 2013 07:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=z6bcCsME0x/b5sAqeQgy3pBElcHws/G9VA3bQ7aagvQ=; b=l6ad5pG4IVBMlPdE6E00jSN/tvPInCl67V1CMN+qpPHtnIjbnCzvB/eq6RsbnZ0nqH Qpac1lE+yvVdA3liQnc9iJo/FQ+fd1SffqeMJ8F7Hz8k1iqCnkfQFQgH7ybOJohqldO8 4THgmJNn3EKvOVW3YP0Qah1ydA7cC3W/7Ikys5IRpCNKH5XbV1UKCN3wk/E/1frD7vqN 2SdS7Ujsdi70tUbrBQeZ7wPG49bBfGK0CLAPDZHJCIt9ciEfeLzJyojAOpBX/wXqNqk5 U+Cjwwq5pbas/k7A2G5YK1MOX+PFwG1m5398evrj7BdM3OYzwB1B/XS03GyrlNYMrlrk 2JjA== X-Received: by 10.152.45.106 with SMTP id l10mr24276938lam.12.1377699631347; Wed, 28 Aug 2013 07:20:31 -0700 (PDT) Received: from dhcp174-208-red.yandex.net (dhcp174-208-red.yandex.net. [95.108.174.208]) by mx.google.com with ESMTPSA id b1sm10635524lah.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 07:20:30 -0700 (PDT) From: Dmitry Sivachenko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 9-STABLE panic on intensive fork Message-Id: Date: Wed, 28 Aug 2013 18:20:29 +0400 To: stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) 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, 28 Aug 2013 14:20:34 -0000 Hello! I am using very recent FreeBSD-9-STABLE snapshot: 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254986: Wed Aug 28 17:18:57 = MSK 2013 I run uwsgi program (ports/www/uwsgi) on that machine. When uwsgi starts, it forks pre-configured number of worker processes. If I raise workers parameter high enough (128), I get kernel panic (100% = reproducible): Fatal trap 12: page fault while in kernel mode If I compile kernel with KDB enabled, I get the following stack: pmap_demote_pde_locked() pmap_copy() vmspace_fork() fork1() sys_fork() I have only remote console for that machine, so I made 2 screenshots: 1) http://people.freebsd.org/~demon/screen1.jpg Panic screen when kernel has no KDB support compiled in 2) http://people.freebsd.org/~demon/screen2.jpg Panic screen (2nd part) with the above stack shown. I can provide any additional information if needed. =20 Thanks!= From owner-freebsd-stable@FreeBSD.ORG Wed Aug 28 17:30:10 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 24EF3613; Wed, 28 Aug 2013 17:30:10 +0000 (UTC) (envelope-from jase@FreeBSD.org) Received: from svr06-mx.btshosting.co.uk (mx-2.btshosting.co.uk [IPv6:2a01:4f8:121:2403:2::]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7EE4329E9; Wed, 28 Aug 2013 17:30:09 +0000 (UTC) Received: from [192.168.1.242] (unknown [90.202.210.251]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by svr06-mx.btshosting.co.uk (Postfix) with ESMTPSA id C85F78829A; Wed, 28 Aug 2013 17:30:07 +0000 (UTC) Message-ID: <521E3394.5050000@FreeBSD.org> Date: Wed, 28 Aug 2013 18:29:56 +0100 From: Jase Thew Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: [HEADS UP] change in devfs path matching logic References: <51F28A33.7040209@FreeBSD.org> <52176C7B.4070701@FreeBSD.org> <20130824230324.12371xhs3clidbi8@webmail.raad.tartu.ee> In-Reply-To: <20130824230324.12371xhs3clidbi8@webmail.raad.tartu.ee> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Toomas Aas , Andriy Gapon 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, 28 Aug 2013 17:30:10 -0000 On 24/08/2013 21:03, Toomas Aas wrote: > Hello! > > On Fri, 23 Aug 2013 Andriy Gapon wrote: > >> >> This change is about to be MFC-ed. >> >> on 26/07/2013 17:39 Andriy Gapon said the following: >>> >>> I have just committed a significant change to devfs path matching logic >>> http://svnweb.freebsd.org/changeset/base/253677 > > I just rebuilt my 8-STABLE i386 system to r254796 and now receive a > kernel panic on boot. If I remove my /etc/devfs.rules file, the panic > does not happen. Can anyone point out what is wrong with my devfs.rules > what the new path matching logic doesn't like? > > $ cat /etc/devfs.rules.old > [localrules=10] > add path "da*" mode 0660 group operator > add path "usb/1.2.0" mode 0660 group uucp > add path "usb/4.3.0" mode 0660 group operator > > > The panic, as transcribed from screen: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06dde21 > stack pointer = 0x28:0xe8690a48 > frame pointer = 0x28:0xe8690a80 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, iopl = 0 > current process = 577 (ln) > trap number = 12 > panic: page fault > KDB: stack backtrace: > #0 0xc0670ece at kdb_backtrace+0x50 > #1 0xc06449fa at panic+0x132 > #2 0xc07eb1d2 at trap_fatal+0x21e > #3 0xc07eb4e0 at trap_pfault+0x1c2 > #4 0xc07ec251 at trap+0x3c1 > #5 0xc07d95fc at calltrap+0x6 > #6 0xc05c7001 at devfs_rule_run+0x13d > #7 0xc05c70c3 at devfs_ruleset_applyde+0x25 > #8 0xc05c71b3 at devfs_rules_apply+0x73 > #9 0xc05cad51 at devfs_symlink+0x124 > #10 0xc080d084 at VOP_SYMLINK_APV+0x4a > #11 0xc06d2985 at kern_symlinkat+0x38b > #12 0xc06d29da at kern_symlink+0x2e > #13 0xc06d2a05 at symlink+0x29 > #14 0xc07eb7c7 at syscall+0x1a1 > #15 0xc07d9661 at Xint0x80_syscall+0x21 > > > Thanks in advance! I'm getting a similar panic with r254986 on stable/8 when starting up jails : # cat /var/crash/version.txt FreeBSD 8.4-STABLE #1 r254986M: Wed Aug 28 16:26:23 BST 2013 root@jailhost.localdomain:/usr/obj/usr/src/sys/JAILHOST # cat /etc/devfs.rules [devfsrules_jailzfs=5] add include $devfsrules_jail add path 'zfs' unhide [devfsrules_jail_tinderbox=6] add include $devfsrules_jail add path 'zfs' unhide add path 'mem' unhide add path 'kmem' unhide # awk '/Fatal trap/,0' /var/crash/msgbuf.txt Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff806f8e46 stack pointer = 0x28:0xffffff812375b670 frame pointer = 0x28:0xffffff812375b6d0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1028 (ln) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff8020466a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0xffffffff80684df7 = kdb_backtrace+0x37 panic() at 0xffffffff806510ce = panic+0x1ce trap_fatal() at 0xffffffff809e8eb0 = trap_fatal+0x290 trap_pfault() at 0xffffffff809e923e = trap_pfault+0x23e trap() at 0xffffffff809e970e = trap+0x3ce calltrap() at 0xffffffff809cf894 = calltrap+0x8 --- trap 0xc, rip = 0xffffffff806f8e46, rsp = 0xffffff812375b670, rbp = 0xffffff812375b6d0 --- fnmatch() at 0xffffffff806f8e46 = fnmatch+0x66 devfs_rule_run() at 0xffffffff805d255b = devfs_rule_run+0x17b devfs_ruleset_applyde() at 0xffffffff805d2621 = devfs_ruleset_applyde+0x31 devfs_rules_apply() at 0xffffffff805d274a = devfs_rules_apply+0x6a devfs_symlink() at 0xffffffff805d624e = devfs_symlink+0x13e VOP_SYMLINK_APV() at 0xffffffff80a78f58 = VOP_SYMLINK_APV+0x68 kern_symlinkat() at 0xffffffff806edc9e = kern_symlinkat+0x38e amd64_syscall() at 0xffffffff809e8484 = amd64_syscall+0x1f4 Xfast_syscall() at 0xffffffff809cfb8c = Xfast_syscall+0xfc --- syscall (57, FreeBSD ELF64, symlink), rip = 0x8006a08bc, rsp = 0x7fffffffd838, rbp = 0x7fffffffed27 --- Uptime: 2m39s Regards, Jase. -- Jase Thew jase@FreeBSD.org FreeBSD Ports Committer From owner-freebsd-stable@FreeBSD.ORG Wed Aug 28 18:25:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2F9F5742 for ; Wed, 28 Aug 2013 18:25:44 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from bouvier.getmail.no (bouvier.getmail.no [84.210.184.8]) by mx1.freebsd.org (Postfix) with ESMTP id D3AAD2D35 for ; Wed, 28 Aug 2013 18:25:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by bouvier.getmail.no (Postfix) with ESMTP id CDCA5428FA for ; Wed, 28 Aug 2013 20:25:35 +0200 (CEST) X-Spam-Flag: NO X-Spam-Score: -2.78 X-Spam-Level: X-Spam-Status: No, score=-2.78 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, T_KHOP_THREADED=-0.01, T_NICE_REPLY_A=0.01, T_UNKNOWN_ORIGIN=0.01] autolearn=no Authentication-Results: bouvier.get.c.bitbit.net (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=getmail.no Received: from bouvier.getmail.no ([127.0.0.1]) by localhost (bouvier.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id hZR2WRvFXv5F for ; Wed, 28 Aug 2013 20:25:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bouvier.getmail.no (Postfix) with ESMTP id 7B2E1428FB for ; Wed, 28 Aug 2013 20:25:35 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.7.1 bouvier.getmail.no 7B2E1428FB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getmail.no; s=8A9C8B4C-D727-11E2-8095-B6466E6B3FA2; t=1377714335; bh=3lxr4Xnl8YWovbSrXfm6t+NXeBRJRMsuolbW/QShGSU=; h=Date:From:To:Subject:Message-Id:Mime-Version:Content-Type: Content-Transfer-Encoding; b=r4BAE+YSoyrXcM4yg3pYhaqm2QaWcBKSMSwmMWtFBZNz5sK6w/iKt+gwElk4YhdFJ PFk3W3DVuDnStvmT5PBOwMi7xyPLDF7h72JmoTqvcs6tWWQvBnOGAvJjDKxx2glVEQ 4E+y7PAi59p3R4UY86fs8+JFHFbnwxxaHqmRtKHA= X-Virus-Scanned: amavisd-new at Received: from bouvier.getmail.no ([127.0.0.1]) by localhost (bouvier.get.c.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0CntE8L_vf2m for ; Wed, 28 Aug 2013 20:25:35 +0200 (CEST) Received: from kg-core1.kg4.no (cm-84.215.180.206.getinternet.no [84.215.180.206]) by bouvier.getmail.no (Postfix) with ESMTPSA id 4A258428FA for ; Wed, 28 Aug 2013 20:25:35 +0200 (CEST) Date: Wed, 28 Aug 2013 20:25:35 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Subject: Re: Suggest changing dirhash defaults for FreeBSD 9.2. Message-Id: <20130828202535.ace8f6c882e94f21f7509966@getmail.no> In-Reply-To: <521D7552.5080008@UToledo.edu> References: <521C9E85.4060801@UToledo.edu> <521D7552.5080008@UToledo.edu> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.19; amd64-portbld-freebsd8.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 18:25:44 -0000 On Tue, 27 Aug 2013 23:58:10 -0400 Robert Burmeister wrote: > > As 64 bit platforms tend to have more RAM and use ZFS, Do you have any numbers for the "64 bit platforms tend to use ZFS"? If not, I will suggest that this is just a theory. FWIW, I haven't abandoned UFS on 64-bit platforms yet (I use ZFS were I need it). Oh, and all people - please trim your quotes. -- Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Wed Aug 28 20:15:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6860C19F for ; Wed, 28 Aug 2013 20:15:54 +0000 (UTC) (envelope-from robert.burmeister@utoledo.edu) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 493A624A5 for ; Wed, 28 Aug 2013 20:15:53 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VElth-0004rF-6o for freebsd-stable@freebsd.org; Wed, 28 Aug 2013 12:59:21 -0700 Date: Wed, 28 Aug 2013 12:59:21 -0700 (PDT) From: Robert_Burmeister To: freebsd-stable@freebsd.org Message-ID: <1377719961203-5839745.post@n5.nabble.com> In-Reply-To: <20130828202535.ace8f6c882e94f21f7509966@getmail.no> References: <521C9E85.4060801@UToledo.edu> <521D7552.5080008@UToledo.edu> <20130828202535.ace8f6c882e94f21f7509966@getmail.no> Subject: Re: Suggest changing dirhash defaults for FreeBSD 9.2. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 20:15:54 -0000 Torfinn Ingolfsen-5 wrote > On Tue, 27 Aug 2013 23:58:10 -0400 > Robert Burmeister < > Robert.Burmeister@ > > wrote: >> >> As 64 bit platforms tend to have more RAM and use ZFS, > Do you have any numbers for the "64 bit platforms tend to use ZFS"? PCBSD and OSX both default to ZFS for their 64 bit installs, and anyone else wanting to use ZFS will choose 64 bit for the address space. Do to the kernel memory constraints, ZFS takes some configuration jiggering to work stably on 32 bit. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Suggest-changing-dirhash-defaults-for-FreeBSD-9-2-tp5839351p5839745.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 28 20:35:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 24E6E72A for ; Wed, 28 Aug 2013 20:35:54 +0000 (UTC) (envelope-from robert.burmeister@utoledo.edu) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0613E2615 for ; Wed, 28 Aug 2013 20:35:53 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VEmT2-0007Hb-Vv for freebsd-stable@freebsd.org; Wed, 28 Aug 2013 13:35:52 -0700 Date: Wed, 28 Aug 2013 13:35:52 -0700 (PDT) From: Robert_Burmeister To: freebsd-stable@freebsd.org Message-ID: <1377722152984-5839755.post@n5.nabble.com> In-Reply-To: References: <521C9E85.4060801@UToledo.edu> <521D7552.5080008@UToledo.edu> Subject: Re: Suggest changing dirhash defaults for FreeBSD 9.2. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 20:35:54 -0000 >>>> I believe that increasing the following values by 10 would benefit >>>> most FreeBSD users without disadvantage. >>>> >>>> vfs.ufs.dirhash_maxmem: 2097152 to 20971520 >>>> >>>> vfs.ufs.dirhash_reclaimage: 5 to 50 or 60 >>> vfs.ufs.dirhash_maxmem is further autotuned based on available >>> physical memory. >>> See r214359 for details. >>> > > To what value does the algorithm tune in your case? On my 16 GB machine, > it's ~~ 25 MB: > > vfs.ufs.dirhash_maxmem: 26968064 > > The policy is to use fractions of the installed RAM (though in a > roundabout way), so it should scale reasonably well to both systems with > large and small memories. > > I'll bump vfs.ufs.dirhash_reclaimage to 60, it's worth it. I'm running 2 Gigs of RAM, so it sets to 2 Megs. As compiling most of the system uses ~1.5 Gigs, I can certainly use the cache. Note that allocated kernel memory does not scale linearly with physical RAM, so a policy to use fractions of kernel memory may be more appropriate. ~25 Megs is a good value, however, as the reclaim value is a portion of vfs.ufs.dirhash_maxmem, a much larger cache and it becomes pyric as it can keep wiping out a small active cache. (I tested vfs.ufs.dirhash_maxmem up to 60 megs.) -- View this message in context: http://freebsd.1045724.n5.nabble.com/Suggest-changing-dirhash-defaults-for-FreeBSD-9-2-tp5839351p5839755.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 28 21:39:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2069FA9A for ; Wed, 28 Aug 2013 21:39:03 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D2C2D2985 for ; Wed, 28 Aug 2013 21:39:02 +0000 (UTC) Received: by mail-qe0-f53.google.com with SMTP id 1so3796885qee.40 for ; Wed, 28 Aug 2013 14:38:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:from:content-type:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=w5t+pv19YlFerX+glI1wOx0G0Ijr8YEBlygN1VgLVmY=; b=dbMY7gb6xQ25mf+/ma276HhDVUXX9c4IOg/CYAgovENPH3wm+JydjW9bBZ7B+C4w/0 8bRRtO7rzmFm2E9v/WvVYr3PCDyHARFWbRjUv/tyZ7Zqk4ACwZnEE7jILI1rnybTtRH7 c6ZKelozjAk+NAbuEKYiiqgIgH6XMs/sOCPoLuKx1mdR2lb5zPwZkVbGRbhDeVamaOw5 zcl08Z2S2NKgJF5tN6d12TUl4DDS5FeuxJFjTbgvJSt0wfcHMx2DdP73hs5dq23POAFC P8HybxoXg8bQzxPsXUnu3bnTjFzrMM22U9ulHnrt2r3NZekLxo6oOf3KeQl0Zk45XuMx lynQ== X-Gm-Message-State: ALoCoQkK2knIB7VxvMNKXuNBYWZl/2MZEQAP/dpouEh/v4lQUKA5kZbBbfBlqvkWKhnlvZeGEBX3 X-Received: by 10.49.63.3 with SMTP id c3mr47497qes.2.1377725579630; Wed, 28 Aug 2013 14:32:59 -0700 (PDT) Received: from [70.204.78.37] (37.sub-70-204-78.myvzw.com. [70.204.78.37]) by mx.google.com with ESMTPSA id z10sm25463817qal.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Aug 2013 14:32:58 -0700 (PDT) Subject: Re: Suggest changing dirhash defaults for FreeBSD 9.2. References: <521C9E85.4060801@UToledo.edu> <521D7552.5080008@UToledo.edu> <20130828202535.ace8f6c882e94f21f7509966@getmail.no> <1377719961203-5839745.post@n5.nabble.com> From: Mark Saad Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (10B329) In-Reply-To: <1377719961203-5839745.post@n5.nabble.com> Message-Id: Date: Wed, 28 Aug 2013 17:32:33 -0400 To: "freebsd-stable@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (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, 28 Aug 2013 21:39:03 -0000 On Aug 28, 2013, at 3:59 PM, Robert_Burmeister wrote: > Torfinn Ingolfsen-5 wrote >> On Tue, 27 Aug 2013 23:58:10 -0400 >> Robert Burmeister < >=20 >> Robert.Burmeister@ >=20 >> > wrote: >>>=20 >>> As 64 bit platforms tend to have more RAM and use ZFS, >> Do you have any numbers for the "64 bit platforms tend to use ZFS"? >=20 > PCBSD and OSX both default to ZFS for their 64 bit installs, > and anyone else wanting to use ZFS will choose 64 bit for the address spac= e. >=20 OSX abandoned zfs back in 10.7, I think you meant Solaris 10 update 5ish and= newer use zfs root by default. fwiw I am using ufs on amd64 too and have o= nly some machines using zfs . > Do to the kernel memory constraints,=20 > ZFS takes some configuration jiggering to work stably on 32 bit. >=20 >=20 >=20 >=20 > -- > View this message in context: http://freebsd.1045724.n5.nabble.com/Suggest= -changing-dirhash-defaults-for-FreeBSD-9-2-tp5839351p5839745.html > Sent from the freebsd-stable mailing list archive at Nabble.com. > _______________________________________________ > 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" Mark saad | mark.saad@longcount.org From owner-freebsd-stable@FreeBSD.ORG Wed Aug 28 22:07:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4A3FD2B4 for ; Wed, 28 Aug 2013 22:07:00 +0000 (UTC) (envelope-from robert.burmeister@utoledo.edu) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2AC9A2B2B for ; Wed, 28 Aug 2013 22:06:59 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VEntD-0005MS-4a for freebsd-stable@freebsd.org; Wed, 28 Aug 2013 15:06:59 -0700 Date: Wed, 28 Aug 2013 15:06:59 -0700 (PDT) From: Robert_Burmeister To: freebsd-stable@freebsd.org Message-ID: <1377727619133-5839769.post@n5.nabble.com> In-Reply-To: References: <521C9E85.4060801@UToledo.edu> <521D7552.5080008@UToledo.edu> Subject: Re: Suggest changing dirhash defaults for FreeBSD 9.2. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 22:07:00 -0000 Ivan Voras-7 wrote > On 28/08/2013 05:58, Robert Burmeister wrote: >> >> On 8/27/2013 9:40 AM, Sergey Kandaurov wrote: >>> On 27 August 2013 16:41, Robert Burmeister >>> < > Robert.Burmeister@ > > wrote: >>>> I believe that increasing the following values by 10 would benefit >>>> most FreeBSD users without disadvantage. >>>> vfs.ufs.dirhash_maxmem: 2097152 to 20971520 >>>> vfs.ufs.dirhash_reclaimage: 5 to 50 or 60 > > I'll bump vfs.ufs.dirhash_reclaimage to 60, it's worth it. Note that vfs.ufs.dirhash_reclaimage is not used to shield ufs_dirhashmem entries, rather all entries older than reclaimage are evicted from the cache on vm_lowmem before evicting a percentage of the oldest remaining entries. If it has been hours since a kernel vm_lowmem event, most of the entries in the cache can be lost due to a momentary memory spike. Also note, under kernel memory pressure continuous vm_lowmem events will effectively extinguish the ufs_dirhash cache, returning its memory to the kernel. I believe this prevents the ufsdirhash cache from in any way contributing to a kernel panic, so bumping vfs.ufs.dirhash_reclaimage to 60 should be riskless. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Suggest-changing-dirhash-defaults-for-FreeBSD-9-2-tp5839351p5839769.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 28 22:14: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B63938C2 for ; Wed, 28 Aug 2013 22:14:21 +0000 (UTC) (envelope-from robert.burmeister@utoledo.edu) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9830E2C10 for ; Wed, 28 Aug 2013 22:14:21 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VEo0K-0005lO-Qk for freebsd-stable@freebsd.org; Wed, 28 Aug 2013 15:14:20 -0700 Date: Wed, 28 Aug 2013 15:14:20 -0700 (PDT) From: Robert_Burmeister To: freebsd-stable@freebsd.org Message-ID: <1377728060824-5839775.post@n5.nabble.com> In-Reply-To: <521C9E85.4060801@UToledo.edu> References: <521C9E85.4060801@UToledo.edu> Subject: Re: Suggest changing dirhash defaults for FreeBSD 9.2. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 22:14:21 -0000 For previous benchmarks on the effect of the dirhash cache see: https://wiki.freebsd.org/DirhashDynamicMemory -- View this message in context: http://freebsd.1045724.n5.nabble.com/Suggest-changing-dirhash-defaults-for-FreeBSD-9-2-tp5839351p5839775.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 01:34:07 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4F60FB1B; Thu, 29 Aug 2013 01:34:07 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from nschwmtas04p.mx.bigpond.com (nschwmtas04p.mx.bigpond.com [61.9.189.146]) by mx1.freebsd.org (Postfix) with ESMTP id B19E6273B; Thu, 29 Aug 2013 01:34:06 +0000 (UTC) Received: from nschwcmgw08p ([61.9.190.168]) by nschwmtas04p.mx.bigpond.com with ESMTP id <20130829013359.SMGT2030.nschwmtas04p.mx.bigpond.com@nschwcmgw08p>; Thu, 29 Aug 2013 01:33:59 +0000 Received: from hermes.heuristicsystems.com.au ([58.172.113.247]) by nschwcmgw08p with BigPond Outbound id JRZz1m00H5LKYmq01RZzr3; Thu, 29 Aug 2013 01:33:59 +0000 X-Authority-Analysis: v=2.0 cv=LvIQOwhc c=1 sm=1 a=YibVxx38Z+cwdCKSMcELyg==:17 a=9F0kiUP6F10A:10 a=twTT4oUKOlYA:10 a=kj9zAlcOel0A:10 a=GHIR_BbyAAAA:8 a=KpPO2GPB2CoA:10 a=6I5d2MoRAAAA:8 a=eDDbEUom-Ko5lA9Eo9wA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=YibVxx38Z+cwdCKSMcELyg==:117 Received: from white (white.hs [10.0.5.2]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id r7T1WKkg056313; Thu, 29 Aug 2013 11:32:21 +1000 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) From: "Dewayne Geraghty" To: "'Ivan Voras'" References: <521C9E85.4060801@UToledo.edu> <521D7552.5080008@UToledo.edu> Subject: RE: Suggest changing dirhash defaults for FreeBSD 9.2. Date: Thu, 29 Aug 2013 11:32:21 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac6j0+GtTebIRBeMSlWovKiHCwdrRwAfpyng X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 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, 29 Aug 2013 01:34:07 -0000 > -----Original Message----- > From: owner-freebsd-stable@freebsd.org > [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Ivan Voras > Sent: Wednesday, 28 August 2013 7:49 PM > To: freebsd-stable@freebsd.org > Subject: Re: Suggest changing dirhash defaults for FreeBSD 9.2. > > On 28/08/2013 05:58, Robert Burmeister wrote: > > > > On 8/27/2013 9:40 AM, Sergey Kandaurov wrote: > >> On 27 August 2013 16:41, Robert Burmeister > >> wrote: > >>> I have been experimenting with dirhash settings, and have scoured > >>> the internet for other peoples' experience with it. > >>> (I found the performance improvement in compiling has forestalled > >>> the need to add an SSD drive. ;-) > >>> > >>> I believe that increasing the following values by 10 > would benefit > >>> most FreeBSD users without disadvantage. > >>> > >>> vfs.ufs.dirhash_maxmem: 2097152 to 20971520 > >>> > >>> vfs.ufs.dirhash_reclaimage: 5 to 50 or 60 > >> vfs.ufs.dirhash_maxmem is further autotuned based on available > >> physical memory. > >> See r214359 for details. > >> > > [Spock Eyebrow of Thought] > > > > I'm running FreeBSD i386 9.2, that allows a max of 4 Gigs of RAM. > > To what value does the algorithm tune in your case? On my 16 > GB machine, it's ~~ 25 MB: > > vfs.ufs.dirhash_maxmem: 26968064 > > > I think the algorithm is still overly conservative for 32 > bit systems, > > which are more likely to be using UFS. > > > > As 64 bit platforms tend to have more RAM and use ZFS, is the same > > tuning algorithm appropriate for both? > > The policy is to use fractions of the installed RAM (though > in a roundabout way), so it should scale reasonably well to > both systems with large and small memories. > > I'll bump vfs.ufs.dirhash_reclaimage to 60, it's worth it. > > > Ivan, >From the analysis perforned in 2009, and referenced earlier by Robert, this https://wiki.freebsd.org/DirhashDynamicMemory and other material at this site, indicates that the reclaimage interval is workload dependent and that 5 to 8 seconds seems, on average, to be adequate. We perform quite a detailed analysis before changing our sysctls for customers' servers that range from 32bit machines with between 1G and 4G of memory, and 64bit with 30G of memory, incidentally all are UFS2. Is the discussion, rather than (synthetic) workload performance, sufficient to warrant changing the default settings by a factor of 12? Regards, Dewayne. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 03:44:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DC159BD8 for ; Thu, 29 Aug 2013 03:44:21 +0000 (UTC) (envelope-from robert.burmeister@utoledo.edu) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF3CB2EBE for ; Thu, 29 Aug 2013 03:44:21 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VEt9g-0000Wn-2t for freebsd-stable@freebsd.org; Wed, 28 Aug 2013 20:44:20 -0700 Date: Wed, 28 Aug 2013 20:44:20 -0700 (PDT) From: Robert_Burmeister To: freebsd-stable@freebsd.org Message-ID: <1377747860047-5839828.post@n5.nabble.com> In-Reply-To: References: <521C9E85.4060801@UToledo.edu> <521D7552.5080008@UToledo.edu> Subject: RE: Suggest changing dirhash defaults for FreeBSD 9.2. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 03:44:22 -0000 Dewayne Geraghty-4 wrote >> I'll bump vfs.ufs.dirhash_reclaimage to 60, it's worth it. > > From the analysis perforned in 2009, and referenced earlier by Robert, > this > https://wiki.freebsd.org/DirhashDynamicMemory and other material at this > site, > indicates that the reclaimage interval is workload dependent and that 5 to > 8 seconds seems, on average, to be adequate. > > We perform quite a detailed analysis before changing our sysctls for > customers' servers that range from 32bit machines with between > 1G and 4G of memory, and 64bit with 30G of memory, incidentally all are > UFS2. Is the discussion, rather than (synthetic) workload > performance, sufficient to warrant changing the default settings by a > factor of 12? > > Regards, Dewayne. I recompile kernel, world and ~1200 ports for every FreeBSD i386 release candidate to detect regressions. Most ports use less than the 2 Gigs of RAM I have to compile, but FireFox, LibreOffice, Sage and others will dig deep into virtual memory. I have observed how the UFS dirhash cache performs during these tasks by periodically running sysctl -a | grep dirhash and I believe it offers noticeable performance improvements for many common tasks, at no risk of loss of performance in other areas, or risk of a kernel panic. I first noticed the UFS dirhash cache because it emulates an old feature of Novel file servers. Most OSs require one disk IO for file metadata and another to access the file. Novel used to store its file metadata in RAM to provide single disk IO file access, at the cost of long boot times. Likewise, the UFS dirhash cache avoids a disk IO for file access when the metadata is in the cache, but only when there is excess memory available for the cache. Since it is an odd on, it was not necessary to change the file system for this increase in performance. This is beneficial for any process requiring disk IO, but especially compiling, mail servers, etc. I have since migrated to SSDs and found the cache to leverage the low latency of SSDs even more. I have read the source code and observed the cache working with high, low and borderline available RAM. Hence determining a cache of > 13 megs is needed to avoid thrashing when rebuilding the ports tree, for instance. I have observed that the UFS dirhash cache gracefully gives back its allocated memory to the kernel before swapping begins, abet with a noticeable drop in performance from dirhash_mem being reduced to insignificance. When kernel memory is again available, the cache will hold its entries indefinitely. Case: if 90% of the cache contains entries from five minutes ago, why should the entries from the last minute that are being used by an active job be lost when dirhash_reclaimage = 60 would clear 90% of the cache on the first vm_lowmem event? In any case, clearing all cache entries older than 5 seconds on every vm_lowmem event keeps the cache from being useful in precisely the circumstances when it would be of most benefit. I suggested vfs.ufs.dirhash_reclaimage = 60 because most bursts of IO tend to fit within >5 - <60 seconds, and I can't think of a case for <=5 seconds. I am interested in hearing other proposals, but I think it shouldn't be difficult to agree that vfs.ufs.dirhash_reclaimage = 5 is too short to really be useful for either servers or desktop users. (Note that 5 seconds was chosen back when the feature was still experimental in 2001.) -- View this message in context: http://freebsd.1045724.n5.nabble.com/Suggest-changing-dirhash-defaults-for-FreeBSD-9-2-tp5839351p5839828.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 07:49:01 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A4B20C06; Thu, 29 Aug 2013 07:49:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C36032BEC; Thu, 29 Aug 2013 07:49:00 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA22095; Thu, 29 Aug 2013 10:48:52 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VEwyK-0002gh-ES; Thu, 29 Aug 2013 10:48:52 +0300 Message-ID: <521EFCAB.5030200@FreeBSD.org> Date: Thu, 29 Aug 2013 10:47:55 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jase Thew , Toomas Aas Subject: Re: [HEADS UP] change in devfs path matching logic References: <51F28A33.7040209@FreeBSD.org> <52176C7B.4070701@FreeBSD.org> <20130824230324.12371xhs3clidbi8@webmail.raad.tartu.ee> <521E3394.5050000@FreeBSD.org> In-Reply-To: <521E3394.5050000@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 07:49:01 -0000 on 28/08/2013 20:29 Jase Thew said the following: > On 24/08/2013 21:03, Toomas Aas wrote: >> Hello! >> >> On Fri, 23 Aug 2013 Andriy Gapon wrote: >> >>> >>> This change is about to be MFC-ed. >>> >>> on 26/07/2013 17:39 Andriy Gapon said the following: >>>> >>>> I have just committed a significant change to devfs path matching logic >>>> http://svnweb.freebsd.org/changeset/base/253677 >> >> I just rebuilt my 8-STABLE i386 system to r254796 and now receive a >> kernel panic on boot. If I remove my /etc/devfs.rules file, the panic >> does not happen. Can anyone point out what is wrong with my devfs.rules >> what the new path matching logic doesn't like? >> >> $ cat /etc/devfs.rules.old >> [localrules=10] >> add path "da*" mode 0660 group operator >> add path "usb/1.2.0" mode 0660 group uucp >> add path "usb/4.3.0" mode 0660 group operator >> >> >> The panic, as transcribed from screen: >> >> Fatal trap 12: page fault while in kernel mode >> fault virtual address = 0x0 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc06dde21 >> stack pointer = 0x28:0xe8690a48 >> frame pointer = 0x28:0xe8690a80 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, iopl = 0 >> current process = 577 (ln) >> trap number = 12 >> panic: page fault >> KDB: stack backtrace: >> #0 0xc0670ece at kdb_backtrace+0x50 >> #1 0xc06449fa at panic+0x132 >> #2 0xc07eb1d2 at trap_fatal+0x21e >> #3 0xc07eb4e0 at trap_pfault+0x1c2 >> #4 0xc07ec251 at trap+0x3c1 >> #5 0xc07d95fc at calltrap+0x6 >> #6 0xc05c7001 at devfs_rule_run+0x13d >> #7 0xc05c70c3 at devfs_ruleset_applyde+0x25 >> #8 0xc05c71b3 at devfs_rules_apply+0x73 >> #9 0xc05cad51 at devfs_symlink+0x124 >> #10 0xc080d084 at VOP_SYMLINK_APV+0x4a >> #11 0xc06d2985 at kern_symlinkat+0x38b >> #12 0xc06d29da at kern_symlink+0x2e >> #13 0xc06d2a05 at symlink+0x29 >> #14 0xc07eb7c7 at syscall+0x1a1 >> #15 0xc07d9661 at Xint0x80_syscall+0x21 >> >> >> Thanks in advance! > > > I'm getting a similar panic with r254986 on stable/8 when starting up jails : Thank you very much for the report. Somehow I missed Toomas'es report on the mailing list. It looks like I should have done more investigation on the state of devfs in stable/8 before MFC-ing the change. There are several earlier big commits that have not been MFC-ed. So, now I can either revert the MFC and be done with it. Or we can try to investigate the crash and see if it's easy to fix it. Do you guys have crashdumps from the panic? > # cat /var/crash/version.txt > FreeBSD 8.4-STABLE #1 r254986M: Wed Aug 28 16:26:23 BST 2013 > root@jailhost.localdomain:/usr/obj/usr/src/sys/JAILHOST > > # cat /etc/devfs.rules > [devfsrules_jailzfs=5] > add include $devfsrules_jail > add path 'zfs' unhide > > [devfsrules_jail_tinderbox=6] > add include $devfsrules_jail > add path 'zfs' unhide > add path 'mem' unhide > add path 'kmem' unhide > > # awk '/Fatal trap/,0' /var/crash/msgbuf.txt > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff806f8e46 > stack pointer = 0x28:0xffffff812375b670 > frame pointer = 0x28:0xffffff812375b6d0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1028 (ln) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff8020466a = db_trace_self_wrapper+0x2a > kdb_backtrace() at 0xffffffff80684df7 = kdb_backtrace+0x37 > panic() at 0xffffffff806510ce = panic+0x1ce > trap_fatal() at 0xffffffff809e8eb0 = trap_fatal+0x290 > trap_pfault() at 0xffffffff809e923e = trap_pfault+0x23e > trap() at 0xffffffff809e970e = trap+0x3ce > calltrap() at 0xffffffff809cf894 = calltrap+0x8 > --- trap 0xc, rip = 0xffffffff806f8e46, rsp = 0xffffff812375b670, rbp = > 0xffffff812375b6d0 --- > fnmatch() at 0xffffffff806f8e46 = fnmatch+0x66 > devfs_rule_run() at 0xffffffff805d255b = devfs_rule_run+0x17b > devfs_ruleset_applyde() at 0xffffffff805d2621 = devfs_ruleset_applyde+0x31 > devfs_rules_apply() at 0xffffffff805d274a = devfs_rules_apply+0x6a > devfs_symlink() at 0xffffffff805d624e = devfs_symlink+0x13e > VOP_SYMLINK_APV() at 0xffffffff80a78f58 = VOP_SYMLINK_APV+0x68 > kern_symlinkat() at 0xffffffff806edc9e = kern_symlinkat+0x38e > amd64_syscall() at 0xffffffff809e8484 = amd64_syscall+0x1f4 > Xfast_syscall() at 0xffffffff809cfb8c = Xfast_syscall+0xfc > --- syscall (57, FreeBSD ELF64, symlink), rip = 0x8006a08bc, rsp = > 0x7fffffffd838, rbp = 0x7fffffffed27 --- > Uptime: 2m39s -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 08:27:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D8F45874 for ; Thu, 29 Aug 2013 08:27:31 +0000 (UTC) (envelope-from maurizio.vairani@cloverinformatica.it) Received: from smtpdg3.aruba.it (smtpdg221.aruba.it [62.149.158.221]) by mx1.freebsd.org (Postfix) with ESMTP id 3D2062EBF for ; Thu, 29 Aug 2013 08:27:30 +0000 (UTC) Received: from cloverinformatica.it ([188.10.129.202]) by smtpcmd01.ad.aruba.it with bizsmtp id JYTT1m01T4N8xN401YTUij; Thu, 29 Aug 2013 10:27:28 +0200 Received: from [192.168.0.81] (ASUS-TERMINATOR [192.168.0.81]) by cloverinformatica.it (Postfix) with ESMTP id 37E729AB4; Thu, 29 Aug 2013 10:27:28 +0200 (CEST) Message-ID: <521F05F0.4090607@cloverinformatica.it> Date: Thu, 29 Aug 2013 10:27:28 +0200 From: Maurizio Vairani User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org, freebsd-stable@FreeBSD.org Subject: Boot problem if a ZFS log device is missing 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, 29 Aug 2013 08:27:31 -0000 Hi all, I am using an USB memory stick as cache and log devices for a HDD ZFS pool named tank0: $ zpool status -v tank0 pool: tank0 state: ONLINE scan: scrub repaired 0 in 7h19m with 0 errors on Tue Jul 30 06:11:23 2013 config: NAME STATE READ WRITE CKSUM tank0 ONLINE 0 0 0 ada0s1d ONLINE 0 0 0 logs gpt/SLOG ONLINE 0 0 0 cache gpt/L2ARC ONLINE 0 0 0 errors: No known data errors If I remove the stick before booting the laptop (a Compaq Presario) it will not boot with the error message: "Mounting from zfs:tank0 failed with error 6" end the mountroot> prompt is displayed. I need to reinsert the stick to completing the boot process before restarting the laptop. It is possible to boots the laptop without stick if I remove the log device with the command: # zpool remove tank0 gpt/SLOG before switching it off. The pool will works in degraded mode because the cache device is missing, but it works. I am able to boot the PC without a cache device but not without a log device. Why ? The laptop is updated to 9.2-PRERELEASE r254783. Regards Maurizio From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 09:02: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 401D4114; Thu, 29 Aug 2013 09:02:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 57E7720F0; Thu, 29 Aug 2013 09:02:31 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA23559; Thu, 29 Aug 2013 12:02:28 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VEy7Y-0002kk-BH; Thu, 29 Aug 2013 12:02:28 +0300 Message-ID: <521F0DEB.20408@FreeBSD.org> Date: Thu, 29 Aug 2013 12:01:31 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Maurizio Vairani Subject: Re: Boot problem if a ZFS log device is missing References: <521F05F0.4090607@cloverinformatica.it> In-Reply-To: <521F05F0.4090607@cloverinformatica.it> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 09:02:33 -0000 on 29/08/2013 11:27 Maurizio Vairani said the following: > > I am able to boot the PC without a cache device but not without a log device. Why ? The log could potentially contain uncommitted entries. Without the log device there is no knowing if it did or did not. And if it did then the pool is inconsistent state without the log device and so it can not be imported. The cache is not persistent and so there is nothing needed from it upon a boot. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 09:07:53 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 237EA377; Thu, 29 Aug 2013 09:07:53 +0000 (UTC) (envelope-from jase@FreeBSD.org) Received: from svr06-mx.btshosting.co.uk (mx-2.btshosting.co.uk [IPv6:2a01:4f8:121:2403:2::]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DC0DD214D; Thu, 29 Aug 2013 09:07:52 +0000 (UTC) Received: from [192.168.1.242] (unknown [90.202.210.251]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by svr06-mx.btshosting.co.uk (Postfix) with ESMTPSA id C024C84BEE; Thu, 29 Aug 2013 09:07:42 +0000 (UTC) Message-ID: <521F0F5E.3070900@FreeBSD.org> Date: Thu, 29 Aug 2013 10:07:42 +0100 From: Jase Thew Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: [HEADS UP] change in devfs path matching logic References: <51F28A33.7040209@FreeBSD.org> <52176C7B.4070701@FreeBSD.org> <20130824230324.12371xhs3clidbi8@webmail.raad.tartu.ee> <521E3394.5050000@FreeBSD.org> <521EFCAB.5030200@FreeBSD.org> In-Reply-To: <521EFCAB.5030200@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 09:07:53 -0000 On 29/08/2013 08:47, Andriy Gapon wrote: > on 28/08/2013 20:29 Jase Thew said the following: >> I'm getting a similar panic with r254986 on stable/8 when starting up jails : > > Thank you very much for the report. Somehow I missed Toomas'es report on the > mailing list. > > It looks like I should have done more investigation on the state of devfs in > stable/8 before MFC-ing the change. There are several earlier big commits that > have not been MFC-ed. > So, now I can either revert the MFC and be done with it. > Or we can try to investigate the crash and see if it's easy to fix it. > > Do you guys have crashdumps from the panic? Hi Andriy, After some fiddling about, I've obtained a crashdump of this panic : http://goo.gl/sRXjo4 If you need anything else, please let me know. Regards, Jase. -- Jase Thew jase@FreeBSD.org FreeBSD Ports Committer From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 09:15:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1D5F452C; Thu, 29 Aug 2013 09:15:19 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B50F921CB; Thu, 29 Aug 2013 09:15:18 +0000 (UTC) Received: by mail-qe0-f47.google.com with SMTP id b4so71839qen.20 for ; Thu, 29 Aug 2013 02:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tA7Htti2OL1zeeRvjcrqUh80iH0lXzTmHQHqCjyxmwc=; b=I5PD/MNrvdzL4zzns3YpmbeGL0S8Aseo39AK9UiO6XpaOnFTdeBTkgMgwJUKphE9UA M12kN1c/4TmsOVwJXokGfWhIZzM0Eic7MO8JqE4MnPDaJs1ZKGvChnFXOCzpBiX/SPfy jLO7kMl6ApzNCfpIENNFA1zdAH7deNPVgmTP2/3qKP8KoY/HuL52ZjOcTtYnNkqGd7fy 6C/Ai3SO7AzRAwDtyCOlNSVK3kP2ZrUagtw1mN13UB31CjvxjzOcLXyg0p/2snXfzcy/ UWmCHf3jqlGewyHhZqrO9xOmY4RsuqC0lJAt66Iy9IEoPmAMUs6Y+0yNBiA1c4s+0xbp pTAg== MIME-Version: 1.0 X-Received: by 10.49.76.98 with SMTP id j2mr2587551qew.41.1377767717789; Thu, 29 Aug 2013 02:15:17 -0700 (PDT) Received: by 10.224.5.195 with HTTP; Thu, 29 Aug 2013 02:15:17 -0700 (PDT) Date: Thu, 29 Aug 2013 12:15:17 +0300 Message-ID: Subject: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? From: Kimmo Paasiala To: FreeBSD current , "freebsd-stable@freebsd.org" , freebsd-hardware@freebsd.org Content-Type: text/plain; charset=UTF-8 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, 29 Aug 2013 09:15:19 -0000 In reference to this FreeBSD forums post: http://forums.freebsd.org/showpost.php?p=231135&postcount=4 Would it be a good time to remove those from GENERIC since the hardware they are for is becoming so seriously outdated? There's always an option to load those drivers as modules if needed. -Kimmo From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 10:12:28 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B4763D08; Thu, 29 Aug 2013 10:12:28 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CB93526E9; Thu, 29 Aug 2013 10:12:27 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA24923; Thu, 29 Aug 2013 13:12:26 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VEzDF-0002oI-Py; Thu, 29 Aug 2013 13:12:25 +0300 Message-ID: <521F1E51.80309@FreeBSD.org> Date: Thu, 29 Aug 2013 13:11:29 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jase Thew Subject: Re: [HEADS UP] change in devfs path matching logic References: <51F28A33.7040209@FreeBSD.org> <52176C7B.4070701@FreeBSD.org> <20130824230324.12371xhs3clidbi8@webmail.raad.tartu.ee> <521E3394.5050000@FreeBSD.org> <521EFCAB.5030200@FreeBSD.org> <521F0F5E.3070900@FreeBSD.org> In-Reply-To: <521F0F5E.3070900@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 10:12:28 -0000 on 29/08/2013 12:07 Jase Thew said the following: > After some fiddling about, I've obtained a crashdump of this panic : > > http://goo.gl/sRXjo4 > > If you need anything else, please let me know. Obviously, I can't do anything with the vmcore without the matching kernel (and perhaps modules). Also, kgdb and libkvm.so from the matching system can be needed. Perhaps you could try examining the devfs_rule_run frame to give a start? Like listing the source code line and examining all local variables. Thank you. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 10:18:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 30402102 for ; Thu, 29 Aug 2013 10:18:13 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DFA262796 for ; Thu, 29 Aug 2013 10:18:12 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VEzIi-0004db-Tb for freebsd-stable@freebsd.org; Thu, 29 Aug 2013 12:18:04 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Aug 2013 12:18:04 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Aug 2013 12:18:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Subject: Re: Suggest changing dirhash defaults for FreeBSD 9.2. Date: Thu, 29 Aug 2013 12:17:50 +0200 Lines: 45 Message-ID: References: <521C9E85.4060801@UToledo.edu> <521D7552.5080008@UToledo.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2FEIUTEQRIICQAPAWFEHB" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130322 Thunderbird/17.0.4 In-Reply-To: X-Enigmail-Version: 1.5.1 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, 29 Aug 2013 10:18:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2FEIUTEQRIICQAPAWFEHB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29/08/2013 03:32, Dewayne Geraghty wrote: > From the analysis perforned in 2009, and referenced earlier by Robert, = this > https://wiki.freebsd.org/DirhashDynamicMemory and other material at thi= s site, > indicates that the reclaimage interval is workload dependent and that 5= to 8 seconds seems, on average, to be adequate. I'm having trouble understanding what the graphs are saying - you seem to have almost consistently worse results with increasing dirhash memory and/or reclaim age. > Is the discussion, rather than (synthetic) workload > performance, sufficient to warrant changing the default settings by a f= actor of 12?=20 Yes, and also for an additional reason on top of what I've already said in @fs and @hackers: it will be at least 10 years before someone remembers to bumb this tunable again, so I consider a little overkill to be ok. ------enig2FEIUTEQRIICQAPAWFEHB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIfH88ACgkQ/QjVBj3/HSzBjwCfcys0NTVXWJEcgy1Oxw0vR2iW 8zEAoI3mw2cZ5rHzMZ+rQ2RlNNR580CY =/TYO -----END PGP SIGNATURE----- ------enig2FEIUTEQRIICQAPAWFEHB-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 10:25:07 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0A10238C; Thu, 29 Aug 2013 10:25:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 202022864; Thu, 29 Aug 2013 10:25:05 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA25062; Thu, 29 Aug 2013 13:25:04 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VEzPU-0002oi-6a; Thu, 29 Aug 2013 13:25:04 +0300 Message-ID: <521F215C.9080900@FreeBSD.org> Date: Thu, 29 Aug 2013 13:24:28 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jase Thew , Toomas Aas Subject: Re: [HEADS UP] change in devfs path matching logic References: <51F28A33.7040209@FreeBSD.org> <52176C7B.4070701@FreeBSD.org> <20130824230324.12371xhs3clidbi8@webmail.raad.tartu.ee> <521E3394.5050000@FreeBSD.org> <521EFCAB.5030200@FreeBSD.org> In-Reply-To: <521EFCAB.5030200@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 10:25:07 -0000 on 29/08/2013 10:47 Andriy Gapon said the following: > It looks like I should have done more investigation on the state of devfs in > stable/8 before MFC-ing the change. There are several earlier big commits that > have not been MFC-ed. > So, now I can either revert the MFC and be done with it. > Or we can try to investigate the crash and see if it's easy to fix it. In fact, I am not sure but I hope that the fix could be as simple as MFC-ing r211847: http://svnweb.freebsd.org/base?view=revision&revision=211847 http://svnweb.freebsd.org/base/head/sys/fs/devfs/devfs_vnops.c?view=patch&r1=211847&r2=211846&pathrev=211847 -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 10:56:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8B254B25 for ; Thu, 29 Aug 2013 10:56:25 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F279A2BA4 for ; Thu, 29 Aug 2013 10:56:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r7TApe7T037020; Thu, 29 Aug 2013 20:51:40 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 29 Aug 2013 20:51:40 +1000 (EST) From: Ian Smith To: Kimmo Paasiala Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? In-Reply-To: Message-ID: <20130829202523.A85171@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 10:56:25 -0000 On Thu, 29 Aug 2013 12:15:17 +0300, Kimmo Paasiala wrote: > To: FreeBSD current , > "freebsd-stable@freebsd.org" , > freebsd-hardware@freebsd.org Just to -stable, as the OP in that forum post's thread was well advised. > In reference to this FreeBSD forums post: > > http://forums.freebsd.org/showpost.php?p=231135&postcount=4 > > Would it be a good time to remove those from GENERIC since the > hardware they are for is becoming so seriously outdated? > > There's always an option to load those drivers as modules if needed. Hardware isn't 'outdated' because you don't use it; FreeBSD has always been thankfully pretty conservative on the planned obsolescence front. If there's a problem with cbb or pccard in a GENERIC kernel that's using neither that disturbs mfi(4), then shouldn't it be identified and fixed, rather than dropping devices from GENERIC to workaround the problem? There's next to no information in that thread to identify the issue/s. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 10:56:56 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 51952CF7; Thu, 29 Aug 2013 10:56:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8C1552BB2; Thu, 29 Aug 2013 10:56:55 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id e11so261723wgh.9 for ; Thu, 29 Aug 2013 03:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rSHv0Hwxj5bF8tKec2UYNfuIn1G++WBwBxYqX5hwcbw=; b=h1G2fGQtGrhuqwKcuCdUfngLyY9iS1DytNl1IqaucnNRZr97ENQUbOgoEUJ7Beb+Bn LB/xwPPAZ5focdJ7JcC0jlLsFcHx6rjsB8VLCVnZQ2aSTXxsxVofx5l9sA97vWUXJWrb YiFWPiNnd7u3jqgDOOnUgWW6TQUnew0UXftUFPqzjrEYjoOKm0iIz/aAKCgkAfLflsuv sEPF9AHcWA0nqkllkVAlNMUqwlxwpJ4kVLNEHdSHozDl7c78oUvn42rWjEnqRM4mT5uS LqfjWWLeafMyyu00MWIWwKkJUqcyQ9/svA92rOIE64cHkMt1T/nVSK9/MhoBtaVClcPG 1Y1A== MIME-Version: 1.0 X-Received: by 10.194.11.67 with SMTP id o3mr5329237wjb.0.1377773813770; Thu, 29 Aug 2013 03:56:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.146.2 with HTTP; Thu, 29 Aug 2013 03:56:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Aug 2013 03:56:53 -0700 X-Google-Sender-Auth: _v3zZf0fjZhtZYfU9HwMxmzXpTo Message-ID: Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? From: Adrian Chadd To: Kimmo Paasiala Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD current , "freebsd-stable@freebsd.org" , freebsd-hardware@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, 29 Aug 2013 10:56:56 -0000 Hm! Are they dynamically loaded if you insert the cards? (Ie, has devd been taught about them as appropriate?) -adrian On 29 August 2013 02:15, Kimmo Paasiala wrote: > In reference to this FreeBSD forums post: > > http://forums.freebsd.org/showpost.php?p=231135&postcount=4 > > Would it be a good time to remove those from GENERIC since the > hardware they are for is becoming so seriously outdated? > > There's always an option to load those drivers as modules if needed. > > -Kimmo > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 11:25: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 89D21781 for ; Thu, 29 Aug 2013 11:25:23 +0000 (UTC) (envelope-from robert.burmeister@utoledo.edu) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6A5D72DA9 for ; Thu, 29 Aug 2013 11:25:22 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VF0Lp-0005Kk-Mq for freebsd-stable@freebsd.org; Thu, 29 Aug 2013 04:25:21 -0700 Date: Thu, 29 Aug 2013 04:25:21 -0700 (PDT) From: Robert_Burmeister To: freebsd-stable@freebsd.org Message-ID: <1377775521691-5839900.post@n5.nabble.com> In-Reply-To: References: <521C9E85.4060801@UToledo.edu> <521D7552.5080008@UToledo.edu> Subject: RE: Suggest changing dirhash defaults for FreeBSD 9.2. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 11:25:23 -0000 I have seen significant benefits from setting the UFS dirhash cache tuneables to effective values, and I believe all FreeBSD users will see at least a small benefit as well. The ball for establishing production defaults appears to have been dropped in 2008. I am suggesting we pick it up and finish the job. (But not necessarily in time for the impending release.) > http://www.freebsd.org/projects/summerofcode-2008.html > Project: Dynamic memory allocation for dirhash in UFS2 > Student: Nick Barkas > Mentor: David Malone > Summary: > > Modified dirhash code in perforce is now able to free up memory used by > older dirhashes when the VM system invokes vm_lowmem events. This will > allow the default dirhash_maxmem value to be increased, improving > performance on large directory lookups when there is memory to spare on > they system. There are versions of the low memory event handling code for > both -CURRENT and 7-STABLE. A number of tests have been run showing the > new event handler seems to work properly. > > I intend to do further testing and benchmarking to find the best default > values to use for vfs.ufs.dirhash_reclaimage (the number of seconds a > dirhash can sit unused before the dirhash low memeory event handler will > unconditionally delete it) and the minimum percentage of memory that will > be freed upon vm_lowmem events even if there are not enough hashes older > than dirhash_reclaimage (currently this is hard coded to 10%). I would > also like to add some code to choose a reasonable new default > vfs.ufs.dirhash_maxmem value based upon the amount of memory in the > system, set automatically at boot time and tunable via sysctl. Once these > tweaks have been made I plan to ask for testing from more users to shake > out any bugs or potential workloads where the new code may hurt overall > performance. If someone has more up to date information please post. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Suggest-changing-dirhash-defaults-for-FreeBSD-9-2-tp5839351p5839900.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 11:26:42 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B38688AD; Thu, 29 Aug 2013 11:26:42 +0000 (UTC) (envelope-from jase@FreeBSD.org) Received: from svr06-mx.btshosting.co.uk (mx-2.btshosting.co.uk [IPv6:2a01:4f8:121:2403:2::]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 760F12DCB; Thu, 29 Aug 2013 11:26:42 +0000 (UTC) Received: from [192.168.1.242] (unknown [90.202.210.251]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by svr06-mx.btshosting.co.uk (Postfix) with ESMTPSA id CBA2088DE9; Thu, 29 Aug 2013 11:26:40 +0000 (UTC) Message-ID: <521F2FF0.3020502@FreeBSD.org> Date: Thu, 29 Aug 2013 12:26:40 +0100 From: Jase Thew Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: [HEADS UP] change in devfs path matching logic References: <51F28A33.7040209@FreeBSD.org> <52176C7B.4070701@FreeBSD.org> <20130824230324.12371xhs3clidbi8@webmail.raad.tartu.ee> <521E3394.5050000@FreeBSD.org> <521EFCAB.5030200@FreeBSD.org> <521F0F5E.3070900@FreeBSD.org> <521F1E51.80309@FreeBSD.org> In-Reply-To: <521F1E51.80309@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 11:26:42 -0000 On 29/08/2013 11:11, Andriy Gapon wrote: > on 29/08/2013 12:07 Jase Thew said the following: >> After some fiddling about, I've obtained a crashdump of this panic : >> >> http://goo.gl/sRXjo4 >> >> If you need anything else, please let me know. > > Obviously, I can't do anything with the vmcore without the matching kernel (and > perhaps modules). Also, kgdb and libkvm.so from the matching system can be needed. > > Perhaps you could try examining the devfs_rule_run frame to give a start? > Like listing the source code line and examining all local variables. > > Thank you. > Hi Andriy, Unless I'm doing something wrong, there doesn't appear to be any useful information contained in the frame other than source line. kgdb script is available at http://goo.gl/ZS8Mjj I'll try merging r211847 as you suggested and will report back. Regards, Jase. -- Jase Thew jase@FreeBSD.org FreeBSD Ports Committer From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 11:44:34 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 871BCDDD for ; Thu, 29 Aug 2013 11:44:34 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0BC472EBD for ; Thu, 29 Aug 2013 11:44:33 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id y6so580280lbh.34 for ; Thu, 29 Aug 2013 04:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3nwDoTYuCjifsRFQuNNdVg59GQIkoUmRecvf5TYAojw=; b=wZrdriO8C+bfN4Z3rfE5iKMJKpBOb7zzh7QS3HpKUkrEh5L62sGxviRe+iCyKLMqak igKgW6eGst8h//lWKEuGymracJIB3ZEquV7DCsuFEqA/gtRNlnNMaJRR1WksUAiJTCfa LM22lNaQN3v4eNOTzhj+Ldw3Bk2ha7+RdT1rnA27Jf73BTA3O2urHhrb68bt0YgIiLDG G8LmCgfIXQBcwyGujUf+UYi1YllE+FP1WAvzEmv3x8/uQqW6r5ioe0RehCUp8Xk3L7Pp njVsJ1mdFc0aPdOAgyKXE4lAAFB/kMiCZ5lhPNATfruyeajvpXshjskOv5A6+0u/QbcC /Y0w== X-Received: by 10.112.172.137 with SMTP id bc9mr2995041lbc.21.1377776671896; Thu, 29 Aug 2013 04:44:31 -0700 (PDT) Received: from [192.168.1.128] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPSA id b6sm12772172lae.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 04:44:31 -0700 (PDT) Message-ID: <521F341C.5040902@gmail.com> Date: Thu, 29 Aug 2013 14:44:28 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 Subject: Re: can't build ^/releng/9.2 from ^/releng/9.1 (resolved) References: <521CE9E4.2060305@gmail.com> In-Reply-To: <521CE9E4.2060305@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 29 Aug 2013 11:44:34 -0000 27.08.2013 21:03, Volodymyr Kostyrko wrote): Was my local glitch, defining INSTALL=install -C in /etc/make.conf shadows install.sh -- Sphinx of black quartz, judge my vow. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 11:58:32 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ADC3089C; Thu, 29 Aug 2013 11:58:32 +0000 (UTC) (envelope-from jase@FreeBSD.org) Received: from svr06-mx.btshosting.co.uk (mx-2.btshosting.co.uk [IPv6:2a01:4f8:121:2403:2::]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F991208C; Thu, 29 Aug 2013 11:58:32 +0000 (UTC) Received: from [192.168.1.242] (unknown [90.202.210.251]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by svr06-mx.btshosting.co.uk (Postfix) with ESMTPSA id 7E98088861; Thu, 29 Aug 2013 11:58:30 +0000 (UTC) Message-ID: <521F3766.40502@FreeBSD.org> Date: Thu, 29 Aug 2013 12:58:30 +0100 From: Jase Thew Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: [HEADS UP] change in devfs path matching logic References: <51F28A33.7040209@FreeBSD.org> <52176C7B.4070701@FreeBSD.org> <20130824230324.12371xhs3clidbi8@webmail.raad.tartu.ee> <521E3394.5050000@FreeBSD.org> <521EFCAB.5030200@FreeBSD.org> <521F215C.9080900@FreeBSD.org> In-Reply-To: <521F215C.9080900@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Toomas Aas , 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, 29 Aug 2013 11:58:32 -0000 On 29/08/2013 11:24, Andriy Gapon wrote: > on 29/08/2013 10:47 Andriy Gapon said the following: >> It looks like I should have done more investigation on the state of devfs in >> stable/8 before MFC-ing the change. There are several earlier big commits that >> have not been MFC-ed. >> So, now I can either revert the MFC and be done with it. >> Or we can try to investigate the crash and see if it's easy to fix it. > > > In fact, I am not sure but I hope that the fix could be as simple as MFC-ing > r211847: > http://svnweb.freebsd.org/base?view=revision&revision=211847 > http://svnweb.freebsd.org/base/head/sys/fs/devfs/devfs_vnops.c?view=patch&r1=211847&r2=211846&pathrev=211847 > Hi Andriy, I've merged that change, rebuilt the kernel and that appears to have resolved the panic. Jails are now starting up correctly with devfs rules being successfully applied. Thanks very much! Regards, Jase. -- Jase Thew jase@FreeBSD.org FreeBSD Ports Committer From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 13:03: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1769E417; Thu, 29 Aug 2013 13:03:24 +0000 (UTC) (envelope-from toomas.aas@raad.tartu.ee) Received: from kuller.raad.tartu.ee (kuller.raad.tartu.ee [213.184.43.8]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF48425B0; Thu, 29 Aug 2013 13:03:23 +0000 (UTC) Received: from kuller.raad.tartu.ee (localhost [127.0.0.1]) by kuller.raad.tartu.ee (Postfix) with ESMTP id E2D3639893; Thu, 29 Aug 2013 16:03:15 +0300 (EEST) X-Virus-Scanned: amavisd-new at post.raad.tartu.ee Received: from kuller.raad.tartu.ee ([127.0.0.1]) by kuller.raad.tartu.ee (kuller.raad.tartu.ee [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QINtYlZLksH4; Thu, 29 Aug 2013 16:03:10 +0300 (EEST) Received: by kuller.raad.tartu.ee (Postfix, from userid 80) id 0408B39885; Thu, 29 Aug 2013 16:03:10 +0300 (EEST) Received: from lv.raad.tartu.ee (lv.raad.tartu.ee [213.184.43.2]) by webmail.raad.tartu.ee (Horde Framework) with HTTP; Thu, 29 Aug 2013 16:03:09 +0300 Message-ID: <20130829160309.128870xup1m22s8w@webmail.raad.tartu.ee> Date: Thu, 29 Aug 2013 16:03:09 +0300 From: Toomas Aas To: Jase Thew Subject: Re: [HEADS UP] change in devfs path matching logic References: <51F28A33.7040209@FreeBSD.org> <52176C7B.4070701@FreeBSD.org> <20130824230324.12371xhs3clidbi8@webmail.raad.tartu.ee> <521E3394.5050000@FreeBSD.org> <521EFCAB.5030200@FreeBSD.org> <521F215C.9080900@FreeBSD.org> <521F3766.40502@FreeBSD.org> In-Reply-To: <521F3766.40502@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) X-Originating-IP: 213.184.43.2 Cc: freebsd-stable@FreeBSD.org, Andriy Gapon 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, 29 Aug 2013 13:03:24 -0000 Hello! On Thu, 29 Aug 2013 Jase Thew wrote: > On 29/08/2013 11:24, Andriy Gapon wrote: >> on 29/08/2013 10:47 Andriy Gapon said the following: >>> It looks like I should have done more investigation on the state >>> of devfs in >>> stable/8 before MFC-ing the change. There are several earlier big >>> commits that >>> have not been MFC-ed. >>> So, now I can either revert the MFC and be done with it. >>> Or we can try to investigate the crash and see if it's easy to fix it. >> >> >> In fact, I am not sure but I hope that the fix could be as simple as MFC-ing >> r211847: >> http://svnweb.freebsd.org/base?view=revision&revision=211847 >> http://svnweb.freebsd.org/base/head/sys/fs/devfs/devfs_vnops.c?view=patch&r1=211847&r2=211846&pathrev=211847 >> > > I've merged that change, rebuilt the kernel and that appears to have > resolved the panic. Jails are now starting up correctly with devfs > rules being successfully applied. Thanks a lot, I'll try this on Saturday when I get my hands on this 8-STABLE system again. -- Toomas Aas From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 13:32:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E3A74D25 for ; Thu, 29 Aug 2013 13:32:48 +0000 (UTC) (envelope-from mvharding@gmail.com) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7C4D1279E for ; Thu, 29 Aug 2013 13:32:48 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id b12so217816wgh.2 for ; Thu, 29 Aug 2013 06:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rWEsYpyQchG0uHcsf6FSgnti9wPQTA0g/zndXb0znb0=; b=cRrUitUFveOtW6iCnOU+7Po2bOpi54Bysyr0ZRpT7nQE3boIL2pSnuz17DbBznsECX bIsL09tB+ms7Osmor9NzYY81mGDhnYUJ7PJ+sDDIKemVXYccNVTQQanUQa9FQaM8szKK gnVhfdD3oYMgj43UJvvG5eUIVvZGnFoecHDNNwHIuKll5BpaTu9rinZMnb69734D02dH c53KGvdXllrY0CkZSqb3HAV49yTpiM9WrTJf5uIo9pXRSRiQ10cn/wWnA11XQzZqRcfN rOTEmHqyYWmCZJHizqJQu/lD/SHOQQ5768w2CPicC9SxLDK9wECwUWbvUP2Viw3SOBR6 SV6w== MIME-Version: 1.0 X-Received: by 10.180.72.47 with SMTP id a15mr35015wiv.63.1377783166896; Thu, 29 Aug 2013 06:32:46 -0700 (PDT) Received: by 10.217.67.69 with HTTP; Thu, 29 Aug 2013 06:32:46 -0700 (PDT) Date: Thu, 29 Aug 2013 06:32:46 -0700 Message-ID: Subject: 9.2-RC3 - suspend/resume causes slow system performance From: Mike Harding To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 13:32:49 -0000 I opened a ticket about this: kern/181632 Basically, if I do a 'zzz' and then wake the system up, operations like a buildworld or portmaster take much longer after the resume - systat shows very low CPU/disk utilization. It's 100% repeatable, I don't recall this happening on 9.1 I build 9.2-RC3 from source (as I have for years) - this is a fairly generic SMP system (i5 750 with 4 cpus). Let me know if I can provide any data - this is a fairly significant regression for me as I have taken to bringing the system up as needed vs. leaving it on all of the time. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 13:40: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7AD2015D; Thu, 29 Aug 2013 13:40:21 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 893D82811; Thu, 29 Aug 2013 13:40:20 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA27652; Thu, 29 Aug 2013 16:40:14 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VF2SL-00033Y-9K; Thu, 29 Aug 2013 16:40:13 +0300 Message-ID: <521F4F19.3070901@FreeBSD.org> Date: Thu, 29 Aug 2013 16:39:37 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Toomas Aas , Jase Thew Subject: Re: [HEADS UP] change in devfs path matching logic References: <51F28A33.7040209@FreeBSD.org> <52176C7B.4070701@FreeBSD.org> <20130824230324.12371xhs3clidbi8@webmail.raad.tartu.ee> <521E3394.5050000@FreeBSD.org> <521EFCAB.5030200@FreeBSD.org> <521F215C.9080900@FreeBSD.org> <521F3766.40502@FreeBSD.org> <20130829160309.128870xup1m22s8w@webmail.raad.tartu.ee> In-Reply-To: <20130829160309.128870xup1m22s8w@webmail.raad.tartu.ee> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 13:40:21 -0000 on 29/08/2013 16:03 Toomas Aas said the following: > Hello! > > On Thu, 29 Aug 2013 Jase Thew wrote: > >> On 29/08/2013 11:24, Andriy Gapon wrote: >>> on 29/08/2013 10:47 Andriy Gapon said the following: >>>> It looks like I should have done more investigation on the state of devfs in >>>> stable/8 before MFC-ing the change. There are several earlier big commits that >>>> have not been MFC-ed. >>>> So, now I can either revert the MFC and be done with it. >>>> Or we can try to investigate the crash and see if it's easy to fix it. >>> >>> >>> In fact, I am not sure but I hope that the fix could be as simple as MFC-ing >>> r211847: >>> http://svnweb.freebsd.org/base?view=revision&revision=211847 >>> http://svnweb.freebsd.org/base/head/sys/fs/devfs/devfs_vnops.c?view=patch&r1=211847&r2=211846&pathrev=211847 >>> >>> >> >> I've merged that change, rebuilt the kernel and that appears to have resolved >> the panic. Jails are now starting up correctly with devfs rules being >> successfully applied. Jase, thank you very much for testing! > Thanks a lot, I'll try this on Saturday when I get my hands on this 8-STABLE > system again. This is now committed to stable/8. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 14:10:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F3B4CF44 for ; Thu, 29 Aug 2013 14:10:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B4E4A2A93 for ; Thu, 29 Aug 2013 14:10:52 +0000 (UTC) Received: by mail-qe0-f51.google.com with SMTP id cy11so223623qeb.10 for ; Thu, 29 Aug 2013 07:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VWEcaSwOmQ8ew42E2m0+eIJARsuNoCgNbISzclyP+q8=; b=Vy8aXSJOQQBUaAgpvhHBXFK7m1HgEAOAXsl6Wv0K4W2hplCHEhhw4d8+jfd5uMTPMw Mq50EFL/NCJVguowq/Mtt8iURb2jZpVLPg4UbHAkmtItJH9qbqqK/G0gspL0SDOaYOuB oKj+O08iOvEytRC1H/SxGCSBKMuAUBbIe+CGqmZJz8EKc9TGXy39qUtRZ+7ete2yg0EW MxMcWFBg/Z12viyotL8krfLTAb3ErrTcSgsMNrJWT7MGvITItbEzAGiPRPl4W2wBmCJz 2pgjCLkMSjllHT9W6fVzqN34YtVLsI5intCkXF+mJX+gHACKkK2zDhzwljb5P8k8wHOZ Plfw== MIME-Version: 1.0 X-Received: by 10.49.62.3 with SMTP id u3mr4152052qer.6.1377785451892; Thu, 29 Aug 2013 07:10:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Thu, 29 Aug 2013 07:10:51 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Aug 2013 07:10:51 -0700 X-Google-Sender-Auth: MGHTVicugZyYe-zIfqG11Dmzn80 Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Adrian Chadd To: Mike Harding Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List 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, 29 Aug 2013 14:10:53 -0000 Wow. Uhm, can you downgrade to 9.1 and see if it still happens? Would you be able to bisect the kernel source and see if you can find where along stable/9 it happened? That's the fastest way to determine what broke. Thanks! -adrian On 29 August 2013 06:32, Mike Harding wrote: > I opened a ticket about this: kern/181632 > > Basically, if I do a 'zzz' and then wake the system up, operations like a > buildworld or portmaster take much longer after the resume - systat shows > very low CPU/disk utilization. It's 100% repeatable, I don't recall this > happening on 9.1 > > I build 9.2-RC3 from source (as I have for years) - this is a fairly > generic SMP system (i5 750 with 4 cpus). > > Let me know if I can provide any data - this is a fairly significant > regression for me as I have taken to bringing the system up as needed vs. > leaving it on all of the time. > _______________________________________________ > 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 Aug 29 14:45:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2378480 for ; Thu, 29 Aug 2013 14:45:11 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id D9A902CF7 for ; Thu, 29 Aug 2013 14:45:10 +0000 (UTC) Received: from mobileKamikaze.norad (MN-VPN2.HS-Karlsruhe.DE [193.196.117.63]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id E7AE886215; Thu, 29 Aug 2013 16:45:07 +0200 (CEST) Message-ID: <521F5E73.90505@bsdforen.de> Date: Thu, 29 Aug 2013 16:45:07 +0200 From: Dominic Fandrey MIME-Version: 1.0 To: Mike Harding Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance References: In-Reply-To: Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 14:45:11 -0000 On 29/08/2013 15:32, Mike Harding wrote: > I opened a ticket about this: kern/181632 > > Basically, if I do a 'zzz' and then wake the system up, operations like a > buildworld or portmaster take much longer after the resume - systat shows > very low CPU/disk utilization. It's 100% repeatable, I don't recall this > happening on 9.1 > > I build 9.2-RC3 from source (as I have for years) - this is a fairly > generic SMP system (i5 750 with 4 cpus). > > Let me know if I can provide any data - this is a fairly significant > regression for me as I have taken to bringing the system up as needed vs. > leaving it on all of the time. I encountered that yesterday. Manually stepping down: sysctl dev.cpu.0.freq=800 And back up again: sysctl dev.cpu.0.freq=2400 fixed this for me. You can simply run powerd to mask the problem. It might have been around for ages as far as I know, because I usually use powerd. I just had it turned of for performance measurements and forgot to turn it back on before going into suspend. When I resumed and reran the tests the performance suddenly was abysmal. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 14:58:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9C6A46B0; Thu, 29 Aug 2013 14:58:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7224F2DBD; Thu, 29 Aug 2013 14:58:20 +0000 (UTC) Received: from jhbbsd.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5F736B9B3; Thu, 29 Aug 2013 10:58:19 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? Date: Thu, 29 Aug 2013 10:54:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308291054.02641.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 29 Aug 2013 10:58:19 -0400 (EDT) Cc: Kimmo Paasiala , Adrian Chadd , "freebsd-stable@freebsd.org" , Warner Losh , freebsd-hardware@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, 29 Aug 2013 14:58:20 -0000 On Thursday, August 29, 2013 6:56:53 am Adrian Chadd wrote: > Hm! Are they dynamically loaded if you insert the cards? > > (Ie, has devd been taught about them as appropriate?) These are drivers for the bridges, not for cards you plug into the bridges. If you autoloaded them at all you would load them during boot when you saw an appropriate PCI device. Currently we don't autoload any PCI drivers, so I don't think that should be a blocker for taking these out of GENERIC. Warner is probably the best person to ask. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 15:25:44 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E79D49BB for ; Thu, 29 Aug 2013 15:25:44 +0000 (UTC) (envelope-from illoai@gmail.com) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C410B201E for ; Thu, 29 Aug 2013 15:25:44 +0000 (UTC) Received: by mail-pb0-f42.google.com with SMTP id un15so602363pbc.15 for ; Thu, 29 Aug 2013 08:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sZ5XLLOeR0nYtiBudV2g4imEq+hAc/SGITPZYeANd3E=; b=UwO6Cu5eQU3wHa5JcALTLfUyWNci2DdH+XNoY0wu2Gao8WeIeZgsmbUsSKpgqNF1SH +MW16fYSu/K8UTH/3cySXuqr3uv37mCSWUD5nmQPJTLl72iNJsWO4D4773MTXNQd0xK6 OXTQwfd3rTnDVUqZ66GNvK3tMa3XBMDrdLUGXWm81R/MDCnWIcaBDGO5lbMTm1/uFazD eu7cam6atR5212QqSCyaTvKxj2WhUFtdZVTp/kXlJRgJgt3HijdOpmAH3dcbXyynBzBQ vtdUy0ikQFcvVtNVx7/qsu80eCsyETfflu1sc3gE++tOHR/dsW9OCXNQfJfxZqemJfFY akgQ== MIME-Version: 1.0 X-Received: by 10.68.131.133 with SMTP id om5mr4300108pbb.148.1377789944376; Thu, 29 Aug 2013 08:25:44 -0700 (PDT) Received: by 10.68.129.99 with HTTP; Thu, 29 Aug 2013 08:25:44 -0700 (PDT) In-Reply-To: <521F341C.5040902@gmail.com> References: <521CE9E4.2060305@gmail.com> <521F341C.5040902@gmail.com> Date: Thu, 29 Aug 2013 11:25:44 -0400 Message-ID: Subject: Re: can't build ^/releng/9.2 from ^/releng/9.1 (resolved) From: "illoai@gmail.com" To: Volodymyr Kostyrko Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 29 Aug 2013 15:25:45 -0000 On 29 August 2013 07:44, Volodymyr Kostyrko wrote: > 27.08.2013 21:03, Volodymyr Kostyrko wrote): > > Was my local glitch, defining INSTALL=install -C in /etc/make.conf shadows > install.sh This is good to know, as bits of my /etc/make.conf date back to 7.0. It looks like the syntax now (via make.conf(5)) is INSTALL+= -C -- -- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 15:32:13 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 43634EB7 for ; Thu, 29 Aug 2013 15:32:13 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BC4C82112 for ; Thu, 29 Aug 2013 15:32:12 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id ec20so516243lab.28 for ; Thu, 29 Aug 2013 08:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=k8KvRF2qUZrIEfejRCp8iRWoUPUTNZbD7slYgysoSOc=; b=xsGSqdE3thTfJhAtqiTGxOkNPebQG4QMK5YPzGc4wWIGFlS+fF2JHR1+zurO8Rm75v 3KHUaWdcCqEJ142f54QQZQiU1lSv4jRODVc+1lGEtrvSj7sedEDSEzJ0y8S4WWs8SayA KSh/NmzsbwIP6Lg3Nyee9s63QgMwaZtdyJOv2lWb+wcTzUe1Ixp9qov5HCTMhHx5jAMj aNLJ70HmS822+E4r3dSudtLiYiyPbPWtK3/q3d9qXsFZPddmgC44BLEE3jRolaGpA2kN 9BIu18vDgOfHtMU4CCI8ywI2iZVwvaT30jIjsuUI6fLy8j5QbhKfR5I0+LvURkAnWkrY HmaQ== X-Received: by 10.152.27.202 with SMTP id v10mr1796792lag.43.1377790330540; Thu, 29 Aug 2013 08:32:10 -0700 (PDT) Received: from [192.168.1.128] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPSA id o1sm13238796lah.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 08:32:09 -0700 (PDT) Message-ID: <521F6978.70801@gmail.com> Date: Thu, 29 Aug 2013 18:32:08 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 MIME-Version: 1.0 To: "illoai@gmail.com" Subject: Re: can't build ^/releng/9.2 from ^/releng/9.1 (resolved) References: <521CE9E4.2060305@gmail.com> <521F341C.5040902@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 29 Aug 2013 15:32:13 -0000 29.08.2013 18:25, illoai@gmail.com wrote: > On 29 August 2013 07:44, Volodymyr Kostyrko wrote: >> 27.08.2013 21:03, Volodymyr Kostyrko wrote): >> >> Was my local glitch, defining INSTALL=install -C in /etc/make.conf shadows >> install.sh > > This is good to know, as bits of my /etc/make.conf > date back to 7.0. Yeah, mine from 4.0 or so... > It looks like the syntax now (via make.conf(5)) is > INSTALL+= -C Actually as I am a ZFS citizen I don't need this anymore as ZFS can simply ignore writes when SHA256 checksum matches. -- Sphinx of black quartz, judge my vow. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 15:50:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6175DDEB for ; Thu, 29 Aug 2013 15:50:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 23748226A for ; Thu, 29 Aug 2013 15:50:21 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id er7so661941obc.31 for ; Thu, 29 Aug 2013 08:50:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=WufppyoDJ8zP1DWHkXsFqxaCpMqK9Zlbk5hkFpuDsJQ=; b=kLMrpG9muN+SGwJjPgOE65flX5vlUIVLayhzdC/BYcgjBGc8uv2iJJgld0jIKxDnM1 dLCHf81h2RxYTDNGK75w57yoDdN4uNxAEioD8vMW+1tfrZ3xktnftiDEjAMoflvN47hl AIz3eqwG+F7sbgesyjMQmgqYDTOH9yAu0t4aj4KQBF2C/hEK+LOgDJK0iX/KU+k43mB4 vg4bB6ybhcxu1pcywlS98AlsaPDVu343NX4xFsHZ83yxHKAXIPmcI/3CcvRnsEDELAJL mH9VKU2cC++9+3j/Nii+qYJzonFpq0Yh0T/ZiBzZpPTkaGRfnl4K9JrkxM56Zh+KkLBD SjAQ== X-Gm-Message-State: ALoCoQm9yfaiSkCrzK4j9EoJMf6Zu3g4NyEXslTXczb6FoDp1j5mwzTfj2gqbjpXVZhELdisoUBo X-Received: by 10.182.48.194 with SMTP id o2mr2259927obn.90.1377791415343; Thu, 29 Aug 2013 08:50:15 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id r3sm33040857oep.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 08:50:14 -0700 (PDT) Sender: Warner Losh Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201308291054.02641.jhb@freebsd.org> Date: Thu, 29 Aug 2013 09:50:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201308291054.02641.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1085) Cc: Adrian Chadd , "freebsd-stable@freebsd.org" , Kimmo Paasiala , freebsd-current@freebsd.org, freebsd-hardware@freebsd.org, Warner Losh 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, 29 Aug 2013 15:50:22 -0000 On Aug 29, 2013, at 8:54 AM, John Baldwin wrote: > On Thursday, August 29, 2013 6:56:53 am Adrian Chadd wrote: >> Hm! Are they dynamically loaded if you insert the cards? >>=20 >> (Ie, has devd been taught about them as appropriate?) >=20 > These are drivers for the bridges, not for cards you plug into the = bridges. =20 > If you autoloaded them at all you would load them during boot when you = saw an=20 > appropriate PCI device. Currently we don't autoload any PCI drivers, = so I=20 > don't think that should be a blocker for taking these out of GENERIC. >=20 > Warner is probably the best person to ask. We don't autoload them. The bridge code is tiny and can easily be = removed if you want to create a custom kernel. There's still plenty of = laptops that would be crippled if these were removed. Other drivers that = are even more obsolete that are still in GENERIC: esp sym trm adv adw aic bt asr ciss iir ida de cas dc gem hme nfe nve pcn (although many VM env like this) rl fs sis tl tx vr wb xl cs ed ex ep fe sn xe an wi urio uipaq aue cue kue rue So asking why cbb and cardbus are still there seems a little silly to = me. The basic problem is that our PCI and USB infrastructure doesn't include = the basic information necessarily to properly look at a directory of .ko = files and know what to autoload when it finds an unmatched device. PC = Card could easily do this, but doesn't (I have some doodles from a few = years ago that would put this stuff into an elf section that could (a) = be unloaded after probe (optionally) and (b) be read by automatic tools = to load just what's needed). USB is a lot closer than PCI, which is why = Hans' scripts work well enough to create uber-ugly devd config files. Rather than shooting randomly, perhaps some investigation about this = topic would be in order. We've talked it to death, but nobody has had = the time to STFU and implement something reasonable. Warner= From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 15:53:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3C4AF137 for ; Thu, 29 Aug 2013 15:53:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EB45B22E8 for ; Thu, 29 Aug 2013 15:52:59 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id er7so666655obc.31 for ; Thu, 29 Aug 2013 08:52:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=bMxC8CwjEN6j179q/GnMvngnd3tZDL1HNqhw0gxmGQ4=; b=fFXTVKEpKU50fYGi9OBC061NTllOhFEB2ykZOrJb9NG1+b4iXMWq8gnzW9mTDgfwQE wX0dTyrcu4PT2JI/OoC+o+SSoQlBdtzfpSYYpDHmXwcl1wzPeOcdLkBE/lTwjWiapZEQ pbw+ZriSzNV/HxIqHycP89I2JZmKJlzWuDhiy8kI4dz90mbpsNPt3/fxJywG9N8vyMCy rKkMrYF2pq9xcPjKJRfGfbr8wQ7v5h+PRMtGWoQKMB82l9phH+uSD6PWi78nKbcVfbaw qHgqQSLjej6v67HfYfzOgDp8gZ0qrhf9ttSb4Ef5qKG3DWnYwko4iv1g00Uw0PUTf7Dd UtHw== X-Gm-Message-State: ALoCoQmRyVNSu56KegnW1ugmJZjeT/duhNQos1a5xlfEQLW9U6gJIpbyiOmEAoPkOuyVkf6Ypa2B X-Received: by 10.182.71.82 with SMTP id s18mr3081962obu.9.1377791579361; Thu, 29 Aug 2013 08:52:59 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id rl1sm33101341oeb.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 08:52:58 -0700 (PDT) Sender: Warner Losh Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 29 Aug 2013 09:52:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <92E50FD0-1A1D-4CD2-AB73-11D1F189D12D@bsdimp.com> References: To: Kimmo Paasiala X-Mailer: Apple Mail (2.1085) Cc: FreeBSD current , "freebsd-stable@freebsd.org" , freebsd-hardware@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, 29 Aug 2013 15:53:00 -0000 On Aug 29, 2013, at 3:15 AM, Kimmo Paasiala wrote: > In reference to this FreeBSD forums post: >=20 > http://forums.freebsd.org/showpost.php?p=3D231135&postcount=3D4 >=20 > Would it be a good time to remove those from GENERIC since the > hardware they are for is becoming so seriously outdated? >=20 > There's always an option to load those drivers as modules if needed. No. It is not a good time to remove them. They aren't as out-dated as = you might think, and there's literally dozens of other devices in = GENERIC that have even less use today... Warner From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 16:01: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3CB66BB1 for ; Thu, 29 Aug 2013 16:01:34 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [64.147.113.26]) by mx1.freebsd.org (Postfix) with ESMTP id 1638A23D6 for ; Thu, 29 Aug 2013 16:01:33 +0000 (UTC) Received: from acm.poly.edu (localhost [127.0.0.1]) by acm.poly.edu (Postfix) with ESMTP id 82F101F13A9 for ; Thu, 29 Aug 2013 11:56:05 -0400 (EDT) Received: (qmail 38558 invoked from network); 29 Aug 2013 15:56:05 -0000 Received: from unknown (HELO ?10.50.50.212?) (spawk@64.147.100.2) by acm.poly.edu with CAMELLIA256-SHA encrypted SMTP; 29 Aug 2013 15:56:05 -0000 Message-ID: <521F6F4A.2080107@acm.poly.edu> Date: Thu, 29 Aug 2013 11:56:58 -0400 From: Boris Kochergin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130828 Thunderbird/17.0.8 MIME-Version: 1.0 Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? References: <92E50FD0-1A1D-4CD2-AB73-11D1F189D12D@bsdimp.com> In-Reply-To: <92E50FD0-1A1D-4CD2-AB73-11D1F189D12D@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current , "freebsd-stable@freebsd.org" , freebsd-hardware@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, 29 Aug 2013 16:01:34 -0000 On 08/29/13 11:52, Warner Losh wrote: > On Aug 29, 2013, at 3:15 AM, Kimmo Paasiala wrote: > >> In reference to this FreeBSD forums post: >> >> http://forums.freebsd.org/showpost.php?p=231135&postcount=4 >> >> Would it be a good time to remove those from GENERIC since the >> hardware they are for is becoming so seriously outdated? >> >> There's always an option to load those drivers as modules if needed. > No. It is not a good time to remove them. They aren't as out-dated as you might think, and there's literally dozens of other devices in GENERIC that have even less use today... > > Warner > Just thought I'd be a statistic and speak up to say that I am happily using the PCMCIA drivers on multiple 9.x/i386 machines, and plan to continue doing so through 10.x. -Boris From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 16:14:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A5BCB535; Thu, 29 Aug 2013 16:14:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1CE0624EE; Thu, 29 Aug 2013 16:14:27 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id i13so539102qae.19 for ; Thu, 29 Aug 2013 09:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=L755AofcUINNwdxYuM3P7OrUWkb8ecn/CWRKz+7P1eE=; b=OJ3CWTjDph/7o+XBsfMQcRKP+IGXAtQnAjUJVliKhbcKINrg7YfiHNDVqtxBHrv08e WGDSorj6bHKR7orVQFsDQj3KRebbZkEP4oklWBwN37DWar+gQfQmUF1vXTFqji5CTbki zdFS1tinuc+1aGlxmRDmhZO98aiQ0C7NwfDizeA5S8Qpy7IaX7wrdxV8tzZMtI57CzoQ doQFT3PTrNExvsgM/gQ5xLyIE5QYStkwLbpW9euYsghuVjWSoomWA+ghQd+m+U2pS02z O14yX+VrxVvAxk8JV2QsSN6ubDhULh7QLuXwmbPpKZBRNHRubZnRa+Xin8IffGhJ+8jw 9XbQ== MIME-Version: 1.0 X-Received: by 10.49.127.179 with SMTP id nh19mr4916627qeb.1.1377792866287; Thu, 29 Aug 2013 09:14:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Thu, 29 Aug 2013 09:14:26 -0700 (PDT) In-Reply-To: References: <201308291054.02641.jhb@freebsd.org> Date: Thu, 29 Aug 2013 09:14:26 -0700 X-Google-Sender-Auth: 2jwJQpWQp_0eUlmzVO7urAFul0o Message-ID: Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org" , John Baldwin , Kimmo Paasiala , freebsd-current , freebsd-hardware@freebsd.org, Warner Losh 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, 29 Aug 2013 16:14:27 -0000 .. after tinkering in the USB world, i wonder what's wrong with this: * created a basic markup / description language to encapsulate what PCI/USB probing requires; * generated both config files _and_ .c / .h files for drivers to include; * have the kernel build process do .device_description -> .c/.h (for compiling) ; devd.conf (for runtime loading); an elf section if you'd like; and loader-mumble.conf (for loader autoloading.) -adrian From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 17:03:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C0CD4F93 for ; Thu, 29 Aug 2013 17:03:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 854352885 for ; Thu, 29 Aug 2013 17:03:28 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id i4so963619oah.9 for ; Thu, 29 Aug 2013 10:03:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=SJDQgzFwJfs4GkD0feBRAHCot6kR8PbIW029am1uuZw=; b=J+LIp5wNGuLMCSiNH8wll8zjdfEuHCuN6gUeGP2tTMwNcNDuhnIMFfVAch7s2DKkVl 9VfGAmXeSFpX86EeeBjIq74L9xV1ivlEXrRpDbJlCG+YDK+7sNht3ukFCA1koD32bs9e KVN5gizMVK1OmhCtVNVXct3+jyogRzt5zdYAWQ+RoNGc17Vms5WFffSUrn0QSstoCJvp c1vjqOSFUVvcgz7b4zHuBUGzar+tADKSsZxJ6qhCUEoQDmnMwStnCij1aT15nuaCQlup 6kAUNj1H+AUJa5Sw78esB3wPLdJs1bZjvHvP7TRr0wXbrnU+rr3ZqS1aRr37YKtddZpE g3oQ== X-Gm-Message-State: ALoCoQnN/MIjjF4feX8penWD8CsakOSLtmwV7nmEghoFD6Wr7RVStT4YKCjW19LdYORXaeErI6Yy X-Received: by 10.60.52.81 with SMTP id r17mr3360989oeo.3.1377795807801; Thu, 29 Aug 2013 10:03:27 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id uz16sm32335159obc.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 10:03:27 -0700 (PDT) Sender: Warner Losh Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 29 Aug 2013 11:03:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <352C0CD1-909B-445A-A1F4-3942D3A3CE3B@bsdimp.com> References: <201308291054.02641.jhb@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1085) Cc: "freebsd-stable@freebsd.org" , John Baldwin , Kimmo Paasiala , freebsd-current , freebsd-hardware@freebsd.org, Warner Losh 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, 29 Aug 2013 17:03:28 -0000 On Aug 29, 2013, at 10:14 AM, Adrian Chadd wrote: > .. after tinkering in the USB world, i wonder what's wrong with this: >=20 > * created a basic markup / description language to encapsulate what = PCI/USB probing requires; > * generated both config files _and_ .c / .h files for drivers to = include; > * have the kernel build process do .device_description -> .c/.h (for = compiling) ; devd.conf (for runtime loading); an elf section if you'd = like; and loader-mumble.conf (for loader autoloading.) It is needlessly complex? You seriously don't need 1/10th that = complexity. We've talked about solutions in the past. I even have something that = will automatically do the heavy lifting for compliant drivers (or did = before it decayed). What's needed is for someone to step in and drive it = to completion. Like I said, this has been talked to death at least half a dozen times. Warner From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 17:39:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 22C5C4C7; Thu, 29 Aug 2013 17:39:01 +0000 (UTC) (envelope-from mueller6721@twc.com) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id B7ADD2AF6; Thu, 29 Aug 2013 17:39:00 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=fJG7LOme c=1 sm=0 a=68NkTaeYMVLl2m++3813FQ==:17 a=i4YerQ4AwY4A:10 a=HSsa_qBhwsUA:10 a=DvSzqBOGy98A:10 a=pedpZTtsAAAA:8 a=ayC55rCoAAAA:8 a=KGjhK52YXX0A:10 a=ORzfrLIX98MA:10 a=6I5d2MoRAAAA:8 a=hDxOVbXN1DwfdmFclnEA:9 a=jjUqNiGvsI0A:10 a=68NkTaeYMVLl2m++3813FQ==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 74.130.200.176 Received: from [74.130.200.176] ([74.130.200.176:44849] helo=localhost) by hrndva-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id C6/82-27973-3378F125; Thu, 29 Aug 2013 17:38:59 +0000 Date: Thu, 29 Aug 2013 17:38:59 +0000 Message-ID: From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? Cc: freebsd-stable@freebsd.org, freebsd-hardware@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, 29 Aug 2013 17:39:01 -0000 > In reference to this FreeBSD forums post: > http://forums.freebsd.org/showpost.php?p=231135&postcount=4 > Would it be a good time to remove those from GENERIC since the > hardware they are for is becoming so seriously outdated? > There's always an option to load those drivers as modules if needed. > -Kimmo These looked useless to me on a desktop computer, but proved necessary to retain just to be able to compile NDIS support into the kernel. This is for a USB wireless adapter by Hiro that uses Realtek RTL8191S chip. Other responses on this topic reveal that these cardbus drivers are needed for many other drivers too. Tom From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 18:45:21 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2D4E6324 for ; Thu, 29 Aug 2013 18:45:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8DDFB2FFE for ; Thu, 29 Aug 2013 18:45:20 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r7TIjFX4068318; Thu, 29 Aug 2013 21:45:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r7TIjFX4068318 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r7TIjFp6068317; Thu, 29 Aug 2013 21:45:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 29 Aug 2013 21:45:15 +0300 From: Konstantin Belousov To: Dmitry Sivachenko Subject: Re: 9-STABLE panic on intensive fork Message-ID: <20130829184515.GN4972@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HwRt59ENP3lSF8Gg" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: 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, 29 Aug 2013 18:45:21 -0000 --HwRt59ENP3lSF8Gg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 28, 2013 at 06:20:29PM +0400, Dmitry Sivachenko wrote: > Hello! >=20 > I am using very recent FreeBSD-9-STABLE snapshot: > 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254986: Wed Aug 28 17:18:57 MSK= 2013 >=20 > I run uwsgi program (ports/www/uwsgi) on that machine. >=20 > When uwsgi starts, it forks pre-configured number of worker processes. > If I raise workers parameter high enough (128), I get kernel panic (100% = reproducible): >=20 > Fatal trap 12: page fault while in kernel mode >=20 > If I compile kernel with KDB enabled, I get the following stack: >=20 > pmap_demote_pde_locked() > pmap_copy() > vmspace_fork() > fork1() > sys_fork() >=20 > I have only remote console for that machine, so I made 2 screenshots: >=20 > 1) http://people.freebsd.org/~demon/screen1.jpg > Panic screen when kernel has no KDB support compiled in >=20 > 2) http://people.freebsd.org/~demon/screen2.jpg > Panic screen (2nd part) with the above stack shown. Look up the source line for the pmap_demote_pde_locked()+0x471 for your kernel. Dump the core from the panic. --HwRt59ENP3lSF8Gg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSH5a6AAoJEJDCuSvBvK1BifYP/jHWVgN/JwglM4uWey15yQEw dZvffpmjsN0E2pVbxJMR9J8VH5dvDivAKBMfYosgPwb+W22jCXAqgm/MLBmX1Evx P7EzXc4i4Td8vbJsvbQp0+WsTl1skLbaOnW3+tVNujoM5YIVJhKwkjSYCJULBmTv CoYG+4CDtbtUfxxAsw3R1Ex/FnV8fcSaOCw8/nAWhR9wKYsDb/vPLGLTAVJHPfhq gz8d11Y1xBMTVDMd0fKnLRWLzdiXHn/A4NpdFvcdDH+vJ0Ggym4uEKqzB58Hplh2 7tD9NmToNl5OtUVLrM7CdkGSC2CCtP0mvTYqFM1icf2hTN1yKF+1sUXW1j8HpvU/ Uw9vL1smqY8kXkReV++lC0rOa/Oo/oYia/Az5FZpseaQhMMl9tVze7DRlnTnfbg3 XkturTOrlWLiajlOiq5ueXzaM0sIGDqtOYMJHEZnZx0/XD5hXLU1dEcptzMemUMh S9SMEM7o8x4ILjSnKFTBTkysxRkdKw2vj1Wj9ICjZhRlroKFdC2pT+RmFoUEI80E 3CO6lS1TBfAP4cZ41INxQ0UddMrvTLuYiAADUdnjdOfVRa0+qhtpR8KaWhR49I3N dWoiFKDxe9bj1DSlLcIjD1/gFJyky/LfGOik9RWaU6Z01vQSHQE5ocItpD8dK/GK d9ZqPh4Kc5IcfHHaGEK3 =A0qD -----END PGP SIGNATURE----- --HwRt59ENP3lSF8Gg-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 18:49:37 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 86928606 for ; Thu, 29 Aug 2013 18:49:37 +0000 (UTC) (envelope-from robert.burmeister@utoledo.edu) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 686FD2071 for ; Thu, 29 Aug 2013 18:49:37 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VF7Hj-0004Uz-Ti for freebsd-stable@freebsd.org; Thu, 29 Aug 2013 11:49:35 -0700 Date: Thu, 29 Aug 2013 11:49:35 -0700 (PDT) From: Robert_Burmeister To: freebsd-stable@freebsd.org Message-ID: <1377802175907-5840090.post@n5.nabble.com> In-Reply-To: <521C9E85.4060801@UToledo.edu> References: <521C9E85.4060801@UToledo.edu> Subject: Re: Suggest changing dirhash defaults for FreeBSD 9.2. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 18:49:37 -0000 Here is a more recent dialog between the developers. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Suggest-changing-dirhash-defaults-for-FreeBSD-9-2-tp5839351p5840090.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 19:42:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E79728E1 for ; Thu, 29 Aug 2013 19:42:40 +0000 (UTC) (envelope-from robert.burmeister@utoledo.edu) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C9F372404 for ; Thu, 29 Aug 2013 19:42:40 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VF875-00083y-Tv for freebsd-stable@freebsd.org; Thu, 29 Aug 2013 12:42:39 -0700 Date: Thu, 29 Aug 2013 12:42:39 -0700 (PDT) From: Robert_Burmeister To: freebsd-stable@freebsd.org Message-ID: <1377805359915-5840115.post@n5.nabble.com> In-Reply-To: <521C9E85.4060801@UToledo.edu> References: <521C9E85.4060801@UToledo.edu> Subject: Re: Suggest changing dirhash defaults for FreeBSD 9.2. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 19:42:41 -0000 After scouring the internet, it seems that no one else has done a great deal of testing of UFS2 dirhash defaults lately. As the dirhash feature has effectively been tested for regressions, I would like to propose setting the default dirhash values to my original recommendation: vfs.ufs.dirhash_maxmem: 20971520 vfs.ufs.dirhash_reclaimage: 60 The last benchmarks from 2008 only tested dirhash_maxmem at 2 and 64 megs. I found in my testing that setting maxmem much over 32 megs makes the UFS dirhash dysfunctional, as scavenging 10% of maxmem on each vm_lowmem event becomes too aggressive. While autotuning defaults is highly desirable, autotuning dirhash_maxmem opens the can of worms of also tuning the hard coded 10% scavenging. It may be better to hard code the maxmem default. It may be appropriate to set the reclaimage to 5 minutes rather than 5 seconds; I consider 60 seconds to still be a very conservative value, but at least an effective one. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Suggest-changing-dirhash-defaults-for-FreeBSD-9-2-tp5839351p5840115.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 21:09:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E05EB2CA for ; Thu, 29 Aug 2013 21:09:57 +0000 (UTC) (envelope-from paul.chakravarti@gmail.com) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 61C842951 for ; Thu, 29 Aug 2013 21:09:57 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id g10so511121eak.18 for ; Thu, 29 Aug 2013 14:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=/LqBroo3iiZRM1YT3dPoNhkMjOh6CTHREglapxU2/G8=; b=b2j9OifxcNXLYYBXvglVfEG4AmN0Jj5woa34ozrK3xAzDCzNKFW47FCX9+n3+Yt0wV ziO8nBQ2w5zfh5x1PcHQgU2pE4REh1Ae951Kqwbq2kawgR+t4yyBwjZRLu+9eB7RcMeU xPtdlWdIwAPV0RWGG89Z2hL9/rktevOLBgwJG/gs0ByMGfzPyW8G3PAkQQNuxPyfAy23 1gGVvA0Ey2SXG51RgKCQCm02qqC19rv6CTQ9BBmZUFTvM2XI0F7TH6f3US17rzZqbPPk Alvf0zbH7XLQ0n8QhkvLtfQgF75LdLfroNgLYRpb2Fy1BEqC9BsmnMmFYwj2ypRlBzLF mAEQ== X-Received: by 10.15.64.1 with SMTP id n1mr7076913eex.15.1377810595606; Thu, 29 Aug 2013 14:09:55 -0700 (PDT) Received: from [10.0.1.125] (cpc5-stav13-2-0-cust54.aztw.cable.virginmedia.com. [94.174.63.55]) by mx.google.com with ESMTPSA id h52sm49299581eez.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 14:09:54 -0700 (PDT) From: Paul Chakravarti Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: OVH KS-2G Random Reboots [FreeBSD 9.1-RELEASE-p6] Date: Thu, 29 Aug 2013 22:09:47 +0100 Message-Id: To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) 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, 29 Aug 2013 21:09:58 -0000 Hello, I was wondering if anyone else is having reboot issues running FreeBSD = 9.1 on the OVH KS-2G low-cost dedicated servers (amazingly cheap at = =A32.49/month - see http://www.ovh.co.uk/dedicated_servers/kimsufi.xml).=20= I am running FreeBSD 9.1-RELEASE-p6 and am getting multiple random = reboots daily (sometimes hours apart, sometimes minutes). Unfortunately there is no evidence anywhere on the system of the cause = of these, in particular nothing at all in logs other then the kernel = coming back up and nothing in /var/crash (I do have dumpdev=3DAUTO in = rc.conf).=20 I am running the standard kernel updated by 'freebsd-update' and have = removed the OVH RTM stuff. There is no particular load on the system at = the time. I suspect that it might be a hardware issue however have tried extended = runs (upto 8 hours) of 'cpuburn' and 'stress' from ports which run fine. = Strangely there seem to be less reboots under heavy load but that may = just be perception. Anyone having similar issues or have any ideas how to diagnose (without = anything in logs, no /var/crash, and no console access not sure what to = try next). Some further info attached if this helps. Thanks, Paul --- demsg.boot Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-RELEASE-p6 #0: Wed Aug 21 20:40:52 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC = amd64 module_register: module pci/em already exists! Module pci/em failed to register: 17 module_register: module pci/lem already exists! Module pci/lem failed to register: 17 CPU: Intel(R) Atom(TM) CPU N2800 @ 1.86GHz (1866.71-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x30661 Family =3D 6 Model =3D 36 = Stepping =3D 1 = Features=3D0xbfebfbff = Features2=3D0x40e39d AMD Features=3D0x20100800 AMD Features2=3D0x1 TSC: P-state invariant, performance statistics real memory =3D 2147483648 (2048 MB) avail memory =3D 2027888640 (1933 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP/HT): APIC ID: 3 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 ctl: CAM Target Layer loaded acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 acpi0: reservation of 0, 4000 (3) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x30d0-0x30d7 mem = 0x80500000-0x805fffff irq 16 at device 2.0 on pci0 pcib1: at device 28.0 on pci0 pci1: on pcib1 em0: port 0x2000-0x201f mem = 0x80400000-0x8041ffff,0x80000000-0x803fffff,0x80420000-0x80423fff irq 16 = at device 0.0 on pci1 em0: Using MSIX interrupts with 3 vectors em0: Ethernet address: 00:22:4d:a6:aa:90 uhci0: port 0x30a0-0x30bf irq = 23 at device 29.0 on pci0 uhci0: LegSup =3D 0x2f00 usbus0 on uhci0 uhci1: port 0x3080-0x309f irq = 19 at device 29.1 on pci0 uhci1: LegSup =3D 0x2f00 usbus1 on uhci1 uhci2: port 0x3060-0x307f irq = 18 at device 29.2 on pci0 uhci2: LegSup =3D 0x2f00 usbus2 on uhci2 uhci3: port 0x3040-0x305f irq = 16 at device 29.3 on pci0 uhci3: LegSup =3D 0x2f00 usbus3 on uhci3 ehci0: mem = 0x80600400-0x806007ff irq 23 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci0 pcib2: at device 30.0 on pci0 pci2: on pcib2 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port = 0x30c8-0x30cf,0x30dc-0x30df,0x30c0-0x30c7,0x30d8-0x30db,0x3020-0x302f = mem 0x80600000-0x806003ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 acpi_button1: on acpi0 ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 orm0: at iomem 0xcf800-0xd07ff,0xd0800-0xd17ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 8 ports with 8 removable, self powered ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 lapic1: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! lapic3: Forcing LINT1 to edge trigger SMP: AP CPU #3 Launched! lapic2: Forcing LINT1 to edge trigger SMP: AP CPU #2 Launched! Timecounter "TSC-low" frequency 14583692 Hz quality 1000 Root mount waiting for: usbus4 ugen4.2: at usbus4 uhub5: = on usbus4 uhub5: 4 ports with 4 removable, self powered Trying to mount root from ufs:/dev/ada0s1a [rw]... cryptosoft0: on motherboard GEOM_ELI: Device ada0s1b.eli created. GEOM_ELI: Encryption: AES-XTS 256 GEOM_ELI: Crypto: software # cat /etc/rc.conf fsck_y_enable=3D"YES" dumpdev=3D"AUTO" cloned_interfaces=3D"lo1" # IPv4 ifconfig_em0=3D" inet 37.187.16.95 netmask 0xffffff00 broadcast = 37.187.16.255" defaultrouter=3D"37.187.16.254" hostname=3D"ks3352212.kimsufi.com" # IPv6 ifconfig_em0_ipv6=3D"inet6 2001:41d0:a:105f::1 prefixlen 64 = accept_rtadv" ipv6_defaultrouter=3D"2001:41D0:A:10ff:ff:ff:ff:ff" # Services ntpdate_enable=3D"YES" ntpdate_hosts=3D"213.186.33.99" syslogd_flags=3D"-s -b 127.0.0.1" sshd_enable=3D"YES" gateway_enable=3D"YES" pf_enable=3D"YES" pflog_enable=3D"YES" ezjail_enable=3D"YES" # ps -axwww PID TT STAT TIME COMMAND 0 ?? DLs 0:00.01 [kernel] 1 ?? ILs 0:00.01 /sbin/init -- 2 ?? DL 0:00.00 [ctl_thrd] 3 ?? DL 0:00.00 [sctp_iterator] 4 ?? DL 0:00.00 [xpt_thrd] 5 ?? DL 0:00.00 [pagedaemon] 6 ?? DL 0:00.00 [vmdaemon] 7 ?? DL 0:00.00 [pagezero] 8 ?? DL 0:00.00 [bufdaemon] 9 ?? DL 0:00.00 [vnlru] 10 ?? DL 0:00.00 [audit] 11 ?? RL 32:07.24 [idle] 12 ?? WL 0:00.31 [intr] 13 ?? DL 0:00.04 [geom] 14 ?? DL 0:00.03 [yarrow] 15 ?? DL 0:00.03 [usb] 16 ?? DL 0:00.01 [syncer] 17 ?? DL 0:00.01 [softdepflush] 62 ?? DL 0:00.00 [crypto] 63 ?? DL 0:00.00 [crypto returns] 64 ?? DL 0:00.00 [g_eli[0] ada0s1b] 65 ?? DL 0:00.00 [g_eli[1] ada0s1b] 66 ?? DL 0:00.00 [g_eli[2] ada0s1b] 67 ?? DL 0:00.00 [g_eli[3] ada0s1b] 1100 ?? Is 0:00.00 /sbin/devd 1107 ?? DL 0:00.00 [pfpurge] 1112 ?? Is 0:00.01 pflogd: [priv] (pflogd) 1118 ?? S 0:00.22 pflogd: [running] -s 116 -i pflog0 -f = /var/log/pflog (pflogd) 1259 ?? Is 0:00.02 /usr/sbin/syslogd -s -b 127.0.0.1 1348 ?? Is 0:00.00 /usr/sbin/sshd 1357 ?? Ss 0:00.01 sendmail: accepting connections (sendmail) 1360 ?? Is 0:00.00 sendmail: Queue runner@00:30:00 for = /var/spool/clientmqueue (sendmail) 1364 ?? Ss 0:00.01 /usr/sbin/cron -s 1421 ?? Ss 0:00.11 sshd: root@pts/0 (sshd) 1401 v0 Is+ 0:00.01 /usr/libexec/getty Pc ttyv0 1402 v1 Is+ 0:00.01 /usr/libexec/getty Pc ttyv1 1403 v2 Is+ 0:00.01 /usr/libexec/getty Pc ttyv2 1404 v3 Is+ 0:00.01 /usr/libexec/getty Pc ttyv3 1405 v4 Is+ 0:00.01 /usr/libexec/getty Pc ttyv4 1406 v5 Is+ 0:00.01 /usr/libexec/getty Pc ttyv5 1407 v6 Is+ 0:00.01 /usr/libexec/getty Pc ttyv6 1408 v7 Is+ 0:00.01 /usr/libexec/getty Pc ttyv7 1423 0 Ss 0:00.05 -csh (csh) 1450 0 R+ 0:00.00 ps -axwww From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 21:35:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D6FC8B47 for ; Thu, 29 Aug 2013 21:35:02 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9903E2B42 for ; Thu, 29 Aug 2013 21:35:02 +0000 (UTC) Received: by mail-ve0-f179.google.com with SMTP id c13so766373vea.24 for ; Thu, 29 Aug 2013 14:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=r+bzcoBP0DnJCJC4vzlZHrelLYLCGt4Cl6AEKcnsFZk=; b=tqWeD3/vCaf1OxGSMBClx8+T0b8szYjlG9vhokbG9JbCWxTT1nFTLL3bN+tJOUS5WM meoQsFoUDqA4DSuSD/PAZ56ZQFyLgjXd/A+nVICym+fBEE04xfroj9Oyzd082UkJ6+6m toBVtqsOcoVmoiAEfqap/MGkgsYbstqu0hPjLjzHUgFW3x8XXM4Zi5sO2HLDU7F/J7/w AQY7m/ZFlAxvh2ayfLmujGWXkzZ65p0kaO2vVpDXLvKNkRs5VzZ2ygZkOgnUXLRIC0ZE O/XTZUpXXlgTrhTli2m1wXVC9vDkFHoT9C8G1Zq0Gme5RRsim6SIhTgm3JkAOrrhpd+x KtXA== MIME-Version: 1.0 X-Received: by 10.52.34.40 with SMTP id w8mr3442442vdi.7.1377812100618; Thu, 29 Aug 2013 14:35:00 -0700 (PDT) Received: by 10.220.122.1 with HTTP; Thu, 29 Aug 2013 14:35:00 -0700 (PDT) Date: Thu, 29 Aug 2013 17:35:00 -0400 Message-ID: Subject: gmirror crash writing to disk? Or is it su+j crash? From: Zaphod Beeblebrox To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 21:35:02 -0000 So I have a system running: FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 03:02:55 EDT 2013 root@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE i386 and it has two 2T SATA disks. To keep this post short, the crash.txt is here. https://uk.eicat.ca/owncloud/public.php?service=files&t=fea9d25579fe0c4afb808859e80e1493 now curiously, while running a "make -j4 buildkernel" ... almost every time ... it crashes with: g_vfs_done():mirror/walke[WRITE(offset=516764794880, length=65536)]error = 11 /usr: got error 11 while accessing filesystem panic: softdep_deallocate_dependencies: unrecovered I/O error ... no error report from the hard drives, simply an error report from the mirror. The filesystem is ufs with su+j... but I'm not sure this matters here. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 21:38:15 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7E3BAD06; Thu, 29 Aug 2013 21:38:15 +0000 (UTC) (envelope-from spork@bway.net) Received: from smtp2.bway.net (smtp2.v6.bway.net [IPv6:2607:d300:1::28]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4C1BD2B78; Thu, 29 Aug 2013 21:38:15 +0000 (UTC) Received: from toasty.sporklab.com (foon.sporktines.com [96.57.144.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: spork@bway.net) by smtp2.bway.net (Postfix) with ESMTPSA id 6EA0495875; Thu, 29 Aug 2013 17:38:07 -0400 (EDT) References: <521F05F0.4090607@cloverinformatica.it> <521F0DEB.20408@FreeBSD.org> In-Reply-To: <521F0DEB.20408@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Charles Sprickman Subject: Re: Boot problem if a ZFS log device is missing Date: Thu, 29 Aug 2013 17:38:06 -0400 To: Andriy Gapon X-Mailer: Apple Mail (2.1085) Cc: Maurizio Vairani , freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 21:38:15 -0000 On Aug 29, 2013, at 5:01 AM, Andriy Gapon wrote: > on 29/08/2013 11:27 Maurizio Vairani said the following: >>=20 >> I am able to boot the PC without a cache device but not without a log = device. Why ? >=20 > The log could potentially contain uncommitted entries. Without the = log device > there is no knowing if it did or did not. And if it did then the pool = is > inconsistent state without the log device and so it can not be = imported. If one is willing to accept that data is lost (like the log device is = totally smoked), is there a way to boot knowing that you may have some = data loss, or is the only option to boot alternate media and force a = pool import (assuming that works without the log device)? Charles >=20 > The cache is not persistent and so there is nothing needed from it = upon a boot. >=20 > --=20 > Andriy Gapon > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 21:52:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E12432E0 for ; Thu, 29 Aug 2013 21:52:52 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id 43B7F2CD4 for ; Thu, 29 Aug 2013 21:52:52 +0000 (UTC) Received: from [192.168.0.128] (4ab54-4-88-163-248-31.fbx.proxad.net [88.163.248.31]) by peterschmitt.fr (Postfix) with ESMTPSA id 896BC60D2 for ; Thu, 29 Aug 2013 23:52:44 +0200 (CEST) Message-ID: <521FC2AB.3040804@peterschmitt.fr> Date: Thu, 29 Aug 2013 23:52:43 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: OVH KS-2G Random Reboots [FreeBSD 9.1-RELEASE-p6] References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GV9Nc0m2xR7HSVwWwOC41AgMUdoufcfkN" 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, 29 Aug 2013 21:52:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GV9Nc0m2xR7HSVwWwOC41AgMUdoufcfkN Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable You're lucky to get your KS-2G=85 I'm still waiting for mine since one mo= nth. Maybe some crypto and/or UFS problems? For the moment I have the old KS-2G at 9=80HT (sorry for conversion), no crypto and I ran 9.1-RELEASE without any problem. Or just one. First I used UFS and during a night, building packages with poudriere, with UFS, the server crashed. So maybe this crash and yours are the same.= However I never got any clue of what happened. And because something went totally wrong after this crash (corrupted file system) I reinstalled in full ZFS. No problem of this kind at all after. Now I use 9.2-RC3 on ZFS and it's still running like a charm. --=20 Florent Peterschmitt | Please: florent@peterschmitt.fr | * Avoid HTML/RTF in E-mail. +33 (0)6 64 33 97 92 | * Send PDF for documents. http://florent.peterschmitt.fr | * Trim your quotations. Really. Proudly powered by Open Source | Thank you :) --GV9Nc0m2xR7HSVwWwOC41AgMUdoufcfkN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSH8KrAAoJEFr01BkajbiBC48P/1vqRWOTVVZJeo8wMV6dGj20 1FUZCX/zvmVgFwWT1PUvMsdbd44lnN8SmZJ0wkdskFqoe3TmRfWc8jNXtIwptm6y rj/vKz6PbboDp/EBk61tzsVfDudmv7ypL9Oi9FvVl6Eyy+aREz4PanDLFd46fsKb CDXYqBa2HcgBbRZNiOt4V2jRr+Z6c5ctHA2AcKcsHCZ0D3vcigApNjYSAVjptbUe fWsQe/VsT5GlUBJgpYOKnmLVHzwGvQyoAPQflhXHr9l6fpuBUSS0hjL+mYjeLwLl +85io9eN2+rUAcmhq3IwRwvBM86D8FDmdxnhLD6lYkxsdHOo3cB0NV/YqWEZZhW7 qMDRWRQ3t4N0MxLdYeiNFBds+WAgADu+Nr2noJk+Q++GZNh7I2NW/vpYnebVGYM8 K2m4qluLBDcwmGrulJs6xqo+sonWJ0+VAMyyo6ytHdgLp+d8k0ZgevoAgaakaZ0D o5tAUguuNUvhfmKl7MrgYTrqMoflpIXCGsiQTgLs7J6WGP7ZxOuEDkk67ZwCKghU +c/yD+kFQQL9iY/WS+Mn1SS/lemw0uY16JzjTEyHk21nlFrsX08g5M1m7TESzx32 iCzHX2d4hTCx47AWXWFxbAdpJRJDx7U+FdaIK47dwgX/ZRqqMihXUvaTcAEA546o Jj/+I+xk2ww0kf2+msJh =uhQI -----END PGP SIGNATURE----- --GV9Nc0m2xR7HSVwWwOC41AgMUdoufcfkN-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 21:54:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 15F763F7 for ; Thu, 29 Aug 2013 21:54:58 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 567382CF3 for ; Thu, 29 Aug 2013 21:54:56 +0000 (UTC) Received: (qmail 57576 invoked by uid 89); 29 Aug 2013 21:54:49 -0000 Received: from unknown (HELO ?192.168.1.201?) (rainer@ultra-secure.de@217.71.83.52) by mail.ultra-secure.de with ESMTPA; 29 Aug 2013 21:54:49 -0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: OVH KS-2G Random Reboots [FreeBSD 9.1-RELEASE-p6] From: Rainer Duffner In-Reply-To: Date: Thu, 29 Aug 2013 23:54:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <16DAA4D4-76A2-4454-B592-4E07EB2E1D64@ultra-secure.de> References: To: Paul Chakravarti X-Mailer: Apple Mail (2.1508) 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, 29 Aug 2013 21:54:58 -0000 Am 29.08.2013 um 23:09 schrieb Paul Chakravarti = : >=20 > Hello, >=20 > I was wondering if anyone else is having reboot issues running FreeBSD = 9.1 on the OVH KS-2G low-cost dedicated servers (amazingly cheap at = =A32.49/month - see http://www.ovh.co.uk/dedicated_servers/kimsufi.xml).=20= >=20 > I am running FreeBSD 9.1-RELEASE-p6 and am getting multiple random = reboots daily (sometimes hours apart, sometimes minutes). >=20 > Unfortunately there is no evidence anywhere on the system of the cause = of these, in particular nothing at all in logs other then the kernel = coming back up and nothing in /var/crash (I do have dumpdev=3DAUTO in = rc.conf).=20 >=20 > I am running the standard kernel updated by 'freebsd-update' and have = removed the OVH RTM stuff. There is no particular load on the system at = the time. >=20 > I suspect that it might be a hardware issue however have tried = extended runs (upto 8 hours) of 'cpuburn' and 'stress' from ports which = run fine. Strangely there seem to be less reboots under heavy load but = that may just be perception. Could it be that under heavy load, the fans spin up and then the whole = rig is actually cooler? Sounds weird, I know. But that was the very first thought that crossed = my mind. Can't you just rent another one, transfer your data and then cancel the = contract on the first? That way, you really get a different rig ;-) From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 22:39:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7F526DF9 for ; Thu, 29 Aug 2013 22:39:17 +0000 (UTC) (envelope-from paul.chakravarti@gmail.com) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 122E52FB9 for ; Thu, 29 Aug 2013 22:39:16 +0000 (UTC) Received: by mail-ea0-f174.google.com with SMTP id z15so541787ead.19 for ; Thu, 29 Aug 2013 15:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=di2/0LFPjrbQI4LbOhn1ATuHIaaB4CgygDSPRjlJB9A=; b=DBXDimRXG7wv5eHoQJwHej6+iv8/VtGXBmaLQdkwMPcJRhoW58w0vcuAabSOV6uZRM XipeqIdsZOib1zcUUx0hQuYIqjE2/T7fwGk6yUG489zLt0VVBvZxeVmC+Rh1RTuAhKx4 1VlK0usnokkqalLaU97ZGsAeToIYKFkASqHkbMkSA2rbiG0H9KuCTTewitmVyUKOkqpN FI2jgNeDLN5Dh6P2STKOKYBJUDAKSOHMt0AG4r2q6mo0w7P/BFRg80CUOgWYeYmp80wg tC8+MzKv6n9NVFr0L83Nkc55yc2RFvGjwdcx3/MrG6rgwahBcQjWS12wmX8XQw+1WOGk GAqQ== X-Received: by 10.14.38.14 with SMTP id z14mr30067eea.89.1377815955330; Thu, 29 Aug 2013 15:39:15 -0700 (PDT) Received: from [10.0.1.125] (cpc5-stav13-2-0-cust54.aztw.cable.virginmedia.com. [94.174.63.55]) by mx.google.com with ESMTPSA id n48sm49874545eeg.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 15:39:14 -0700 (PDT) Subject: Re: OVH KS-2G Random Reboots [FreeBSD 9.1-RELEASE-p6] Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Paul Chakravarti In-Reply-To: <16DAA4D4-76A2-4454-B592-4E07EB2E1D64@ultra-secure.de> Date: Thu, 29 Aug 2013 23:39:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <624E4579-9AC2-4C35-8AAC-11D1AFC58A49@gmail.com> References: <16DAA4D4-76A2-4454-B592-4E07EB2E1D64@ultra-secure.de> To: Rainer Duffner X-Mailer: Apple Mail (2.1283) 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, 29 Aug 2013 22:39:17 -0000 On 29 Aug 2013, at 22:54, Rainer Duffner wrote: >=20 > Am 29.08.2013 um 23:09 schrieb Paul Chakravarti = : >=20 >>=20 >> Hello, >>=20 >> I was wondering if anyone else is having reboot issues running = FreeBSD 9.1 on the OVH KS-2G low-cost dedicated servers (amazingly cheap = at =A32.49/month - see = http://www.ovh.co.uk/dedicated_servers/kimsufi.xml).=20 >>=20 >> I am running FreeBSD 9.1-RELEASE-p6 and am getting multiple random = reboots daily (sometimes hours apart, sometimes minutes). >>=20 >> Unfortunately there is no evidence anywhere on the system of the = cause of these, in particular nothing at all in logs other then the = kernel coming back up and nothing in /var/crash (I do have dumpdev=3DAUTO = in rc.conf).=20 >>=20 >> I am running the standard kernel updated by 'freebsd-update' and have = removed the OVH RTM stuff. There is no particular load on the system at = the time. >>=20 >> I suspect that it might be a hardware issue however have tried = extended runs (upto 8 hours) of 'cpuburn' and 'stress' from ports which = run fine. Strangely there seem to be less reboots under heavy load but = that may just be perception. >=20 >=20 >=20 > Could it be that under heavy load, the fans spin up and then the whole = rig is actually cooler? >=20 > Sounds weird, I know. But that was the very first thought that crossed = my mind. >=20 > Can't you just rent another one, transfer your data and then cancel = the contract on the first? >=20 > That way, you really get a different rig ;-) >=20 That's an interesting idea. I have loaded coretemp and monitored CPU = temp during the stress tests (which is pretty stable) but could be = something else on the board. Transferring to new box is a good idea, unfortunately they have sold out = (and have a huge backlog) but hopefully this will sort itself out = shortly. Other then the reboots (!) it's a really good box. Paul =20 From owner-freebsd-stable@FreeBSD.ORG Thu Aug 29 23:11:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3C99A98C for ; Thu, 29 Aug 2013 23:11:38 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by mx1.freebsd.org (Postfix) with ESMTP id C78B521BB for ; Thu, 29 Aug 2013 23:11:35 +0000 (UTC) Received: from ppp118-210-148-95.lns20.adl6.internode.on.net (HELO leader.local) ([118.210.148.95]) by ipmail05.adl6.internode.on.net with ESMTP; 30 Aug 2013 08:41:34 +0930 Message-ID: <521FD51D.5070306@ShaneWare.Biz> Date: Fri, 30 Aug 2013 08:41:25 +0930 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130516 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Chakravarti Subject: Re: OVH KS-2G Random Reboots [FreeBSD 9.1-RELEASE-p6] References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 23:11:38 -0000 On 30/08/2013 06:39, Paul Chakravarti wrote: > I am running FreeBSD 9.1-RELEASE-p6 and am getting multiple random > reboots daily (sometimes hours apart, sometimes minutes). > I suspect that it might be a hardware issue however have tried > extended runs (upto 8 hours) of 'cpuburn' and 'stress' from ports > which run fine. Strangely there seem to be less reboots under heavy > load but that may just be perception. Any chance it panics going to sleep? Full load keeps it awake. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 00:11:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E65D453D for ; Fri, 30 Aug 2013 00:11:25 +0000 (UTC) (envelope-from andyf@andyit.com.au) Received: from smtp.syd.comcen.com.au (smtp.syd.comcen.com.au [203.23.236.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7D2C624FB for ; Fri, 30 Aug 2013 00:11:24 +0000 (UTC) Received: from hummer.af.speednet.com.au (115-69-4-237.dyn.comcen.net.au [115.69.4.237]) by smtp.syd.comcen.com.au (8.13.4/8.12.9) with ESMTP id r7U07L4d090139 for ; Fri, 30 Aug 2013 10:07:21 +1000 (EST) Received: from snuggles.af.speednet.com.au (snuggles.af.speednet.com.au [172.22.2.2]) by hummer.af.speednet.com.au (8.14.5/8.14.5) with ESMTP id r7U07GtD031511 for ; Fri, 30 Aug 2013 10:07:16 +1000 (EST) (envelope-from andyf@andyit.com.au) Message-ID: <521FE233.4050102@andyit.com.au> Date: Fri, 30 Aug 2013 10:07:15 +1000 From: Andy Farkas User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120614 Thunderbird/13.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? References: <201308291054.02641.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-comcen-MailScanner-Information: Please contact the ISP for more information X-comcen-MailScanner: Found to be clean X-comcen-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.212, required 4, AWL -0.31, BAYES_50 0.00, RDNS_DYNAMIC 0.10) X-comcen-MailScanner-From: andyf@andyit.com.au 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, 30 Aug 2013 00:11:26 -0000 > There's still plenty of laptops that would be crippled if these were removed. > Indeed: dc0: port 0x1000-0x10ff mem 0x88000000-0x880003ff irq 11 at device 0.0 on cardbus1 -andyf From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 06:46:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 497199AB; Fri, 30 Aug 2013 06:46:30 +0000 (UTC) (envelope-from mvharding@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD36229F1; Fri, 30 Aug 2013 06:46:29 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id q58so1222057wes.39 for ; Thu, 29 Aug 2013 23:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JlfXvolm9BMvj/SY4ArLBJUy6qHxBXeKCeVPHiWdntA=; b=gt4eTnFZPU39895nqHglytOQr6/MzDGXD2pYnl68Ru0MnuVHHL+slORHARTJ9dKOcv odaIf/aUBQluHhpiXEadfT2fOy5BPigo5I2uWRwF/7bvrhOaspXoiZ7V/0+ENaPxCim5 mYwsIH8tItdIXx6cca2jDY+e6wi1M8T96Qs3UStLUSI0KLtoTgS6C58bBrSKd/CK/6gU PPtguv8bLl1R3OYj33w3obKtRYFQ0YDDcU5wbFbtSORp2C0DwNVKWGtFKTLecgGQhoq6 93kiVDuWGGEUQPyJbF+p+5uNnhrEPcZQfdanY0+THXeBUkGdAisPAYmh6WKex9yu0wz2 64TQ== MIME-Version: 1.0 X-Received: by 10.180.75.15 with SMTP id y15mr1100988wiv.12.1377845188019; Thu, 29 Aug 2013 23:46:28 -0700 (PDT) Received: by 10.217.67.69 with HTTP; Thu, 29 Aug 2013 23:46:27 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Aug 2013 23:46:27 -0700 Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Mike Harding To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List 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, 30 Aug 2013 06:46:30 -0000 I was able to track this down by building kernels against /base/stable/9 (it took -hours!-). The issue does occur with commit 244616, but does not occur with 244614. The only difference is a small patch to /usr/src/sys/dev/acpica/acpi_cpu.c - this code appears to do with c-state processing. I'll note it in the ticket, but somebody might want to look at this ASAP On Thu, Aug 29, 2013 at 7:10 AM, Adrian Chadd wrote: > Wow. Uhm, can you downgrade to 9.1 and see if it still happens? > > Would you be able to bisect the kernel source and see if you can find > where along stable/9 it happened? That's the fastest way to determine what > broke. > > Thanks! > > > > -adrian > > > > On 29 August 2013 06:32, Mike Harding wrote: > >> I opened a ticket about this: kern/181632 >> >> Basically, if I do a 'zzz' and then wake the system up, operations like a >> buildworld or portmaster take much longer after the resume - systat shows >> very low CPU/disk utilization. It's 100% repeatable, I don't recall this >> happening on 9.1 >> >> I build 9.2-RC3 from source (as I have for years) - this is a fairly >> generic SMP system (i5 750 with 4 cpus). >> >> Let me know if I can provide any data - this is a fairly significant >> regression for me as I have taken to bringing the system up as needed vs. >> leaving it on all of the time. >> _______________________________________________ >> 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 Aug 30 06:50:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 20E3EB00; Fri, 30 Aug 2013 06:50:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8151D2A32; Fri, 30 Aug 2013 06:50:21 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id q54so1236229wes.19 for ; Thu, 29 Aug 2013 23:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=l19ubGoZDThO/pTAirzCqnB4B042Mafxo8ryvJhdLhA=; b=an5RA3cxbEdhGLvRnYyV1v7W4tw7HONpLKvgqGzEC3XFcMDPpbPZwDEmwDKzyz26fS uEgy4J7LqF/W6TFKB8wuqe6oQTUisa8AKIcSgWe6G1mJT/CbBc+PXttsODj1+t7P29Rj PHOcnRnW+Pxuhx0NcZuxJUn3RMvWK+i87d22RiJWD4YsguBPLdEan9P9c6ij0KUtEN7q 2RAf41GEOcqqnmyZRL2dRd0oQ8YghJ0NYRBfb+f+Hypys83NNKU0ZKK/599/RMg5eU0A VJsfu24cVi6GpX0i3cBQVoxmp/+VSdE930aLQteifjufBboKoO7NuzUi3Dt1ZBcotYBU gLkw== MIME-Version: 1.0 X-Received: by 10.180.8.42 with SMTP id o10mr1160881wia.0.1377845419919; Thu, 29 Aug 2013 23:50:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.146.2 with HTTP; Thu, 29 Aug 2013 23:50:19 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Aug 2013 23:50:19 -0700 X-Google-Sender-Auth: ZEsNmLDszwben7aAwW4bDYGRDSo Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Adrian Chadd To: Mike Harding , "freebsd-acpi@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List 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, 30 Aug 2013 06:50:22 -0000 On 29 August 2013 23:46, Mike Harding wrote: > I was able to track this down by building kernels against /base/stable/9 > (it took > -hours!-). > Wow, thanks! > The issue does occur with commit 244616, but does not occur with 244614. > The > only difference is a small patch to /usr/src/sys/dev/acpica/acpi_cpu.c - > this > code appears to do with c-state processing. I'll note it in the ticket, > but somebody > might want to look at this ASAP > That's awesome. It's a very small ACPI patch. Let's see if the others who are having this issue can test this out and report back! Thanks! -adrian From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 08:17: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E007081A for ; Fri, 30 Aug 2013 08:17:15 +0000 (UTC) (envelope-from maurizio.vairani@cloverinformatica.it) Received: from smtpdg8.aruba.it (smtpdg226.aruba.it [62.149.158.226]) by mx1.freebsd.org (Postfix) with ESMTP id 447C5207E for ; Fri, 30 Aug 2013 08:17:14 +0000 (UTC) Received: from cloverinformatica.it ([188.10.129.202]) by smtpcmd03.ad.aruba.it with bizsmtp id JwHB1m01N4N8xN401wHCpk; Fri, 30 Aug 2013 10:17:12 +0200 Received: from [192.168.0.81] (ASUS-TERMINATOR [192.168.0.81]) by cloverinformatica.it (Postfix) with ESMTP id 449A113914; Fri, 30 Aug 2013 10:17:12 +0200 (CEST) Message-ID: <52205507.4030802@cloverinformatica.it> Date: Fri, 30 Aug 2013 10:17:11 +0200 From: Maurizio Vairani User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: Boot problem if a ZFS log device is missing References: <521F05F0.4090607@cloverinformatica.it> <521F0DEB.20408@FreeBSD.org> In-Reply-To: <521F0DEB.20408@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 08:17:15 -0000 On 29/08/2013 11.01, Andriy Gapon wrote: > on 29/08/2013 11:27 Maurizio Vairani said the following: >> I am able to boot the PC without a cache device but not without a log device. Why ? > The log could potentially contain uncommitted entries. Without the log device > there is no knowing if it did or did not. And if it did then the pool is > inconsistent state without the log device and so it can not be imported. > > The cache is not persistent and so there is nothing needed from it upon a boot. > Thank you for the clear and concise reply. Yesterday I have done some test. If I remove the stick from the USB port, before the shutdown the PC, it don't crash but continues to works. Then I am able to reboot the laptop without inserting the stick with a pool that works in degraded mode. From the end user point of view a PC should always boot, even with a missing ZFS log device. Regards Maurizio From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 09:49:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 06B3AF38 for ; Fri, 30 Aug 2013 09:49:33 +0000 (UTC) (envelope-from robert.burmeister@utoledo.edu) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DCF7F264C for ; Fri, 30 Aug 2013 09:49:31 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VFLKW-0002w8-Td for freebsd-stable@freebsd.org; Fri, 30 Aug 2013 02:49:24 -0700 Date: Fri, 30 Aug 2013 02:49:24 -0700 (PDT) From: Robert_Burmeister To: freebsd-stable@freebsd.org Message-ID: <1377856164912-5840292.post@n5.nabble.com> In-Reply-To: <1377805359915-5840115.post@n5.nabble.com> References: <521C9E85.4060801@UToledo.edu> <1377805359915-5840115.post@n5.nabble.com> Subject: Re: Suggest changing dirhash defaults for FreeBSD 9.2. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 09:49:33 -0000 Observation relevant to tuning vfs.ufs.dirhash_maxmem: When swap is in use dirhash_mem hovers between 10% and 20% of dirhash_maxmem due to frequent scavenging. This indicates active dirhash_mem effectively behaves differently during low memory, and that the dirhash_reclaimage setting is effectively irrelevant during low memory. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Suggest-changing-dirhash-defaults-for-FreeBSD-9-2-tp5839351p5840292.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 10:02: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CF1205B3 for ; Fri, 30 Aug 2013 10:02:12 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 915812741 for ; Fri, 30 Aug 2013 10:02:12 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id x12so747994qcv.26 for ; Fri, 30 Aug 2013 03:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+CSA3B81FosYzGavgnxOuUmAkHrTBQSeDGyRgdSlIt8=; b=DGsllPayndbwV6yKULrpY6MrBTZ2RFc98796Nz7nytdXbQHJi3sYhiUUxrwCgYYu0f hUqQGlOLZ61q8/j9gWlSoxFuRIxB0vw2bHxIZVIb/jyZ9diX3HT2ej6nqP5eeWkCI/o5 gy4k1cggqHS0WdpyOuaJ4aOWbNlXJBLND7rLCbzIxgXfKI/01jsyQ3wCEmi5P8J+BfMT 2TfFRRgjFXrBoycT80HaukeSjR5/8fIaZ2RWbIcU5fpU0berTR9/XdpBOe9vRou1A+ST fGj6ZqHhhoQt5M9TwEkm5GuhTKtBeGmhUzYlv4SvNc/nx2SNdV6YcvlrG+XQgwx43P+q 3erA== MIME-Version: 1.0 X-Received: by 10.224.20.7 with SMTP id d7mr10650819qab.2.1377856931744; Fri, 30 Aug 2013 03:02:11 -0700 (PDT) Received: by 10.224.5.195 with HTTP; Fri, 30 Aug 2013 03:02:11 -0700 (PDT) In-Reply-To: <521FE233.4050102@andyit.com.au> References: <201308291054.02641.jhb@freebsd.org> <521FE233.4050102@andyit.com.au> Date: Fri, 30 Aug 2013 13:02:11 +0300 Message-ID: Subject: Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC? From: Kimmo Paasiala To: Andy Farkas 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: Fri, 30 Aug 2013 10:02:12 -0000 On Fri, Aug 30, 2013 at 3:07 AM, Andy Farkas wrote: >> There's still plenty of laptops that would be crippled if these were >> removed. >> > > Indeed: > > dc0: port 0x1000-0x10ff mem > 0x88000000-0x880003ff irq 11 at device 0.0 on cardbus1 > > -andyf > Just to be clear, I'm not suggesting to retire the drivers but to take them out of the GENERIC kernel config and move them to be loaded as modules only. Adrian Chadd undestood perfectly what I was after. -Kimmo From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 10:38: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D87811FD; Fri, 30 Aug 2013 10:38:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EFE2F2970; Fri, 30 Aug 2013 10:38:39 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA11720; Fri, 30 Aug 2013 13:38:33 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VFM64-0007bu-PU; Fri, 30 Aug 2013 13:38:32 +0300 Message-ID: <522075D6.70600@FreeBSD.org> Date: Fri, 30 Aug 2013 13:37:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Charles Sprickman Subject: Re: Boot problem if a ZFS log device is missing References: <521F05F0.4090607@cloverinformatica.it> <521F0DEB.20408@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Maurizio Vairani , freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 10:38:40 -0000 on 30/08/2013 00:38 Charles Sprickman said the following: > If one is willing to accept that data is lost (like the log device is totally smoked), is there a way to boot knowing that you may have some data loss, or is the only option to boot alternate media and force a pool import (assuming that works without the log device)? I think it's the latter. I am not aware of any way to select a behavior similar to import -m or import -F during boot. Perhaps... ZFS_IMPORT_MISSING_LOG should be a default behavior for a root pool or maybe the behavior could be controllable by a tunable. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 10:47:26 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3863768D; Fri, 30 Aug 2013 10:47:26 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5134C2A08; Fri, 30 Aug 2013 10:47:24 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA12017; Fri, 30 Aug 2013 13:47:21 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VFMEa-0007cl-No; Fri, 30 Aug 2013 13:47:20 +0300 Message-ID: <52207800.2060901@FreeBSD.org> Date: Fri, 30 Aug 2013 13:46:24 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: Maurizio Vairani Subject: Re: Boot problem if a ZFS log device is missing References: <521F05F0.4090607@cloverinformatica.it> <521F0DEB.20408@FreeBSD.org> <522075D6.70600@FreeBSD.org> In-Reply-To: <522075D6.70600@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, Charles Sprickman , 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, 30 Aug 2013 10:47:26 -0000 on 30/08/2013 13:37 Andriy Gapon said the following: > on 30/08/2013 00:38 Charles Sprickman said the following: >> If one is willing to accept that data is lost (like the log device is totally smoked), is there a way to boot knowing that you may have some data loss, or is the only option to boot alternate media and force a pool import (assuming that works without the log device)? > > I think it's the latter. I am not aware of any way to select a behavior similar > to import -m or import -F during boot. > Perhaps... ZFS_IMPORT_MISSING_LOG should be a default behavior for a root pool > or maybe the behavior could be controllable by a tunable. > Maurizio, you might want to try the following patch as an interim solution for your environment: --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c @@ -4112,6 +4112,7 @@ spa_import_rootpool(const char *name) } spa->spa_is_root = B_TRUE; spa->spa_import_flags = ZFS_IMPORT_VERBATIM; + spa->spa_import_flags |= ZFS_IMPORT_MISSING_LOG; /* XXX make tunable */ /* * Build up a vdev tree based on the boot device's label config. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 10:58:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 13DE78BC for ; Fri, 30 Aug 2013 10:58:33 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A6872A88 for ; Fri, 30 Aug 2013 10:58:32 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id g10so830106eak.4 for ; Fri, 30 Aug 2013 03:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Ve8nByE8SboqeQJBZ/iUoWnbqYsSFcU/hC8aUJif9JU=; b=USDyBkm6kdHYnwZsKkAl7HwHeB8fNvaLG30TSdVhbdQVsZphCRSSryr1ApDA39+CB9 pmHFVxs6kIahdNA1eVe2cuyfuobAT0Bb/7MtoB7l/+Q0rArz0Zlcqxcbvkpe+FOfvahG j1Hm6pRt5XndDxfmdKw0cStbcteNFnVkVMRdvRff/YdOWEnnLPNReWDv2OQMZpWPgQhn 7iQyLHXjLbrPPw3KbLYxXSTeTVlFKdc6qHaxZr/wtOb/LDtyhtGMoVe120NsqbyVlrUI fjHKDPTgUdc8+u/0AbuNPI/TVlW8WMVnFTQMM5GzycNtHg8cEJDJUPY0LR8B09E9bdWD ubcQ== X-Received: by 10.14.87.135 with SMTP id y7mr2312284eee.69.1377860310170; Fri, 30 Aug 2013 03:58:30 -0700 (PDT) Received: from [192.168.1.129] ([193.173.55.180]) by mx.google.com with ESMTPSA id a43sm53711005eep.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 03:58:29 -0700 (PDT) Message-ID: <52207AD5.2070608@gmail.com> Date: Fri, 30 Aug 2013 12:58:29 +0200 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Maurizio Vairani Subject: Re: Boot problem if a ZFS log device is missing References: <521F05F0.4090607@cloverinformatica.it> <521F0DEB.20408@FreeBSD.org> <52205507.4030802@cloverinformatica.it> In-Reply-To: <52205507.4030802@cloverinformatica.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 30 Aug 2013 10:58:33 -0000 Maurizio Vairani wrote: > On 29/08/2013 11.01, Andriy Gapon wrote: >> on 29/08/2013 11:27 Maurizio Vairani said the following: >>> I am able to boot the PC without a cache device but not without a >>> log device. Why ? >> The log could potentially contain uncommitted entries. Without the >> log device >> there is no knowing if it did or did not. And if it did then the >> pool is >> inconsistent state without the log device and so it can not be imported. >> >> The cache is not persistent and so there is nothing needed from it >> upon a boot. >> > Thank you for the clear and concise reply. > > Yesterday I have done some test. If I remove the stick from the USB > port, before the shutdown the PC, it don't crash but continues to > works. Then I am able to reboot the laptop without inserting the > stick with a pool that works in degraded mode. > > From the end user point of view a PC should always boot, even with a > missing ZFS log device. > > Regards > Maurizio > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" I do not agree with the following. From the end user point of view a PC should always boot, even with a missing ZFS log device. I think it should give you a option to import the pool or not import the pool! There could be a situation when you are not sure that the ZIL is commited, in that situation it would be handy if you can suspend the boot and make sure the ZIL is there when you reboot or import after you attached the ZIL. I would hate it when it corrups my data just because we always import. with or without the ZIL. In your test you remove the ZIL, and when you reboot then it imports correctly, as far as my knowledge goes this is ok, because when the pool is exported there is no left data in the ZIL, it was not there when we exported, so we can import even without the missing ZIL without problem. regards Johan From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 11:45:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3FD7B861 for ; Fri, 30 Aug 2013 11:45:16 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews07.kpnxchange.com (cpsmtpb-ews07.kpnxchange.com [213.75.39.10]) by mx1.freebsd.org (Postfix) with ESMTP id AA34F2D65 for ; Fri, 30 Aug 2013 11:45:15 +0000 (UTC) Received: from cpsps-ews01.kpnxchange.com ([10.94.84.168]) by cpsmtpb-ews07.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 30 Aug 2013 13:45:14 +0200 Received: from CPSMTPM-TLF104.kpnxchange.com ([195.121.3.7]) by cpsps-ews01.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 30 Aug 2013 13:45:13 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF104.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 30 Aug 2013 13:45:13 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 8C46CC600; Fri, 30 Aug 2013 13:45:13 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Maurizio Vairani" , "Johan Hendriks" Subject: Re: Boot problem if a ZFS log device is missing References: <521F05F0.4090607@cloverinformatica.it> <521F0DEB.20408@FreeBSD.org> <52205507.4030802@cloverinformatica.it> <52207AD5.2070608@gmail.com> Date: Fri, 30 Aug 2013 13:45:13 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <52207AD5.2070608@gmail.com> User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 30 Aug 2013 11:45:14.0038 (UTC) FILETIME=[63DB8D60:01CEA576] X-RcptDomain: freebsd.org 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: Fri, 30 Aug 2013 11:45:16 -0000 On Fri, 30 Aug 2013 12:58:29 +0200, Johan Hendriks wrote: > Maurizio Vairani wrote: >> On 29/08/2013 11.01, Andriy Gapon wrote: >>> on 29/08/2013 11:27 Maurizio Vairani said the following: >>>> I am able to boot the PC without a cache device but not without a log >>>> device. Why ? >>> The log could potentially contain uncommitted entries. Without the >>> log device >>> there is no knowing if it did or did not. And if it did then the pool >>> is >>> inconsistent state without the log device and so it can not be >>> imported. >>> >>> The cache is not persistent and so there is nothing needed from it >>> upon a boot. >>> >> Thank you for the clear and concise reply. >> >> Yesterday I have done some test. If I remove the stick from the USB >> port, before the shutdown the PC, it don't crash but continues to >> works. Then I am able to reboot the laptop without inserting the stick >> with a pool that works in degraded mode. >> >> From the end user point of view a PC should always boot, even with a >> missing ZFS log device. >> >> Regards >> Maurizio >> >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > I do not agree with the following. > From the end user point of view a PC should always boot, even with > a missing ZFS log device. > > I think it should give you a option to import the pool or not import the > pool! > There could be a situation when you are not sure that the ZIL is > commited, in that situation it would be handy if you can suspend the > boot and make sure the ZIL is there when you reboot or import after you > attached the ZIL. > I would hate it when it corrups my data just because we always import. > with or without the ZIL. > > In your test you remove the ZIL, and when you reboot then it imports > correctly, as far as my knowledge goes this is ok, because when the pool > is exported there is no left data in the ZIL, it was not there when we > exported, so we can import even without the missing ZIL without problem. I think he was just lucky his system wasn't writing a lot to the ZIL at the moment of removal. So his system was in a consistent state. Otherwise you just miss data which is in the ZIL and not on disk. BTW: Not everything goes through the ZIL. It is not the same as a journal. Only sync writes go to the ZIL. If you don't use databases or NFS or other software which wants to make sure data is on stable storage, you might rarely use the ZIL. Ronald. > > regards > Johan > > > > > > _______________________________________________ > 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 Aug 30 12:10:07 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6341942B for ; Fri, 30 Aug 2013 12:10:07 +0000 (UTC) (envelope-from maurizio.vairani@cloverinformatica.it) Received: from smtpdg1.aruba.it (smtpdg1.aruba.it [62.149.158.231]) by mx1.freebsd.org (Postfix) with ESMTP id BB3C02EFF for ; Fri, 30 Aug 2013 12:10:06 +0000 (UTC) Received: from cloverinformatica.it ([188.10.129.202]) by smtpcmd01.ad.aruba.it with bizsmtp id K09x1m00H4N8xN40109xKj; Fri, 30 Aug 2013 14:09:58 +0200 Received: from [192.168.0.81] (ASUS-TERMINATOR [192.168.0.81]) by cloverinformatica.it (Postfix) with ESMTP id 7E61411A57; Fri, 30 Aug 2013 14:09:57 +0200 (CEST) Message-ID: <52208B95.2010100@cloverinformatica.it> Date: Fri, 30 Aug 2013 14:09:57 +0200 From: Maurizio Vairani User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ronald Klop , Johan Hendriks Subject: Re: Boot problem if a ZFS log device is missing References: <521F05F0.4090607@cloverinformatica.it> <521F0DEB.20408@FreeBSD.org> <52205507.4030802@cloverinformatica.it> <52207AD5.2070608@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 30 Aug 2013 12:10:07 -0000 On 30/08/2013 13.45, Ronald Klop wrote: > On Fri, 30 Aug 2013 12:58:29 +0200, Johan Hendriks > wrote: > >> Maurizio Vairani wrote: >>> On 29/08/2013 11.01, Andriy Gapon wrote: >>>> on 29/08/2013 11:27 Maurizio Vairani said the following: >>>>> I am able to boot the PC without a cache device but not without a >>>>> log device. Why ? >>>> The log could potentially contain uncommitted entries. Without the >>>> log device >>>> there is no knowing if it did or did not. And if it did then the >>>> pool is >>>> inconsistent state without the log device and so it can not be >>>> imported. >>>> >>>> The cache is not persistent and so there is nothing needed from it >>>> upon a boot. >>>> >>> Thank you for the clear and concise reply. >>> >>> Yesterday I have done some test. If I remove the stick from the USB >>> port, before the shutdown the PC, it don't crash but continues to >>> works. Then I am able to reboot the laptop without inserting the >>> stick with a pool that works in degraded mode. >>> >>> From the end user point of view a PC should always boot, even with a >>> missing ZFS log device. >>> >>> Regards >>> Maurizio >>> >>> _______________________________________________ >>> freebsd-fs@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> I do not agree with the following. >> From the end user point of view a PC should always boot, even >> with a missing ZFS log device. >> >> I think it should give you a option to import the pool or not import >> the pool! No problem I agree, a step in the right direction. >> There could be a situation when you are not sure that the ZIL is >> commited, in that situation it would be handy if you can suspend the >> boot and make sure the ZIL is there when you reboot or import after >> you attached the ZIL. >> I would hate it when it corrups my data just because we always >> import. with or without the ZIL. >> >> In your test you remove the ZIL, and when you reboot then it imports >> correctly, as far as my knowledge goes this is ok, because when the >> pool is exported there is no left data in the ZIL, it was not there >> when we exported, so we can import even without the missing ZIL >> without problem. > > I think he was just lucky his system wasn't writing a lot to the ZIL > at the moment of removal. So his system was in a consistent state. > Otherwise you just miss data which is in the ZIL and not on disk. I have removed the stick when there isn't R/W to the disk. > BTW: Not everything goes through the ZIL. It is not the same as a > journal. Only sync writes go to the ZIL. If you don't use databases or > NFS or other software which wants to make sure data is on stable > storage, you might rarely use the ZIL. Thanks for the explanation. > > Ronald. > >> >> regards >> Johan >> >> >> >> >> >> _______________________________________________ >> 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" Regards Maurizio From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 12:47:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CAA9BE94 for ; Fri, 30 Aug 2013 12:47:05 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A57892196 for ; Fri, 30 Aug 2013 12:47:05 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id z10so1816993pdj.31 for ; Fri, 30 Aug 2013 05:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S1lEx7uYCs2Jnp/Xv0oQYu29MgTEHW7Ov6McA19H2Vk=; b=quwAC8f780f3xH25bN+wXkwjMjVHh/gZXbAZ4C6zb9waCcawdXru92GWsGlyHqhYfW XbRn8MK3596HIvClopZdervCiH3rxaTPrhm1prKVk1jIgEsNYHaqchBOPRkhIB/APLDP /V3jLI+kGkeykmm+X07zZnZUBgKcocIj9phmsBxjLhurzbJZ+CaAenjtiT92iFCD2lZk 8AMQlD4m5DTeHJB31vTOtg82JKy4BXT+Olgw9dlKJ6hDMweI2lQQbzeH/v1VVzg1GvN6 cSFzQjiw7NuMk/0J826dE9disVo/mI16or1vo7hxx7PrkXFvzYxsL43GekRUS9CkAI0A n9SA== MIME-Version: 1.0 X-Received: by 10.68.245.227 with SMTP id xr3mr9376339pbc.182.1377866824971; Fri, 30 Aug 2013 05:47:04 -0700 (PDT) Received: by 10.70.92.79 with HTTP; Fri, 30 Aug 2013 05:47:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 30 Aug 2013 07:47:04 -0500 Message-ID: Subject: Re: gmirror crash writing to disk? Or is it su+j crash? From: Adam Vande More To: Zaphod Beeblebrox Content-Type: text/plain; charset=ISO-8859-1 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: Fri, 30 Aug 2013 12:47:05 -0000 On Thu, Aug 29, 2013 at 4:35 PM, Zaphod Beeblebrox wrote: > So I have a system running: > > FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 > 03:02:55 > EDT 2013 root@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE i386 > > and it has two 2T SATA disks. To keep this post short, the crash.txt is > here. > > > https://uk.eicat.ca/owncloud/public.php?service=files&t=fea9d25579fe0c4afb808859e80e1493 > > now curiously, while running a "make -j4 buildkernel" ... almost every time > ... it crashes with: > > g_vfs_done():mirror/walke[WRITE(offset=516764794880, length=65536)]error = > 11 > /usr: got error 11 while accessing filesystem > panic: softdep_deallocate_dependencies: unrecovered I/O error > > ... no error report from the hard drives, simply an error report from the > mirror. > > The filesystem is ufs with su+j... but I'm not sure this matters here. > > Run fsck. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 15:31:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EC7294C5 for ; Fri, 30 Aug 2013 15:31:48 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 86E4E2D29 for ; Fri, 30 Aug 2013 15:31:48 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id ey11so6376979wid.6 for ; Fri, 30 Aug 2013 08:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EoXIC0Cq42zNV4W+DS5Hz2jKZC6Bw2ybTEfSZK3tcJA=; b=N4+kLmgezE0xUxnssWtnJkJomZWakkwVjks1LxTrSli9bMErLz2gJSEwFCYUuvFgfF 2sJCxHAmwtaxHfcA92yq6Mi2KGAlMCCtd0gmmn42hPX8DaWiBxhfhJYJkj9JHooYS+u2 FkbboTmwCZFvI6gloyaTJMycYs20awrn8Hwz5Ta1Ut/v31KYO0X9ZHmQ5ds0/BYxQs8O K/X63cSnNYzM35exCgoZx3C5/s3syb/97WUximdTwqige7emaxbE20WvK2M7kj/TlnGb IIQjKNE0Hdm4eb9UTAqsBAK14oeDFbfpe1qPggZSpM5CtnUyZsHTkPdmN6x+XRNjGRuV mTEQ== MIME-Version: 1.0 X-Received: by 10.194.176.74 with SMTP id cg10mr377159wjc.75.1377876705667; Fri, 30 Aug 2013 08:31:45 -0700 (PDT) Received: by 10.194.157.69 with HTTP; Fri, 30 Aug 2013 08:31:45 -0700 (PDT) Date: Fri, 30 Aug 2013 17:31:45 +0200 Message-ID: Subject: Some PR never seen to delete From: David Demelier To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 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, 30 Aug 2013 15:31:49 -0000 Hi, In the past I've sent some PR that has never been seen, I think we should close them now. 2010/09/16 kern/150628 [acd] [ata] burncd(1) can't write to optical drive 2010/07/14 ports/148591 x11 information note for x11-drivers/xf86-input-synaptic 2010/12/01 kern/152750 wireless[ath] ath0 lot of bad series hwrate 2010/12/12 bin/153052 [patch] watch(8) breaks tty on error 2011/01/25 ports/154288 glewis[patch] games/nethack*: remove old ports and cleanup latest 2011/02/07 kern/154567 wireless[ath] ath(4) lot of bad series(0) 2011/07/01 conf/158557rc [patch] /etc/rc.d/pf broken messages 2012/11/05 kern/173408 acpi[acpi] [regression] ACPI Regression: battery does not update often 2012/11/22 kern/173840 snd_hda(4) volume mixer not working anymore 2012/11/24 kern/173896 Kernel does not boot if splash loaded and hint.sc.0.vesa_mode set 2012/12/23 ports/174650 xfcex11-wm/xfce4 crash with exaGetPixmapFirstPixel called for invalid bpp 1 2012/12/28 kern/174766 acpi[acpi] Random acpi panic 2013/01/31 kern/175722 wireless[ath]lot of bad seriesx hwrate in kernel messages Some are still valid but will never been taken so I propose to close them. Cheers, -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 19:23:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C90EECB6 for ; Fri, 30 Aug 2013 19:23:05 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 881D129D5 for ; Fri, 30 Aug 2013 19:23:05 +0000 (UTC) Received: by mail-vb0-f44.google.com with SMTP id e13so1585669vbg.17 for ; Fri, 30 Aug 2013 12:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c4NG6PMAHHa2lMOSAp46yYvi7GWohLhHpq+LfX5xPvo=; b=Aa4Pkk5y22kq03A259pJZkycMCFRk94TEpc8KCLB1QaOXz5fauf4g1q2G7T0ZRGU0O VJdgjY0VGSC2Wf99es8gzKA1TgbVMdwJBF89rPuSTNls6GYp+Eud7jh+EcBK1uVsvEZ8 TqRDTDQcrjKiwfH1KSVBESbYQfV6SzOAIf/BLTwQc/IuBHYyzJkCPfR08JpCQD/G9A0L q5Z4Eo8sBcNiSo4H9iGgrLIadL7GkQPuvcxR/vUQ4Tdu8rs4uaOvpXGTL7/eyrL+pM9K YyhUoF04lHEQyS57xviaapfngfbmG6QO8w3ZNY62ZLS9s0jh8w4mdWnSwMOdgbhkU3LC nNJA== MIME-Version: 1.0 X-Received: by 10.52.164.102 with SMTP id yp6mr7709864vdb.14.1377890583221; Fri, 30 Aug 2013 12:23:03 -0700 (PDT) Received: by 10.220.122.1 with HTTP; Fri, 30 Aug 2013 12:23:03 -0700 (PDT) In-Reply-To: References: Date: Fri, 30 Aug 2013 15:23:03 -0400 Message-ID: Subject: Re: gmirror crash writing to disk? Or is it su+j crash? From: Zaphod Beeblebrox To: Adam Vande More Content-Type: text/plain; charset=ISO-8859-1 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: Fri, 30 Aug 2013 19:23:05 -0000 I was going to mention that I ran fsck _twice_, but I forgot. Then when that didn't fix it, I dumped the filesystem, newfs'd it and restored it. Then I fsck'd it for good measure. This particular crash immediately follows that treatment. I can do this in a loop: boot -> make -j4 buildkernel -> crash -> single user -> fsck -> fsck again -\ ^-------------------------------------------------------------------------/ On Fri, Aug 30, 2013 at 8:47 AM, Adam Vande More wrote: > On Thu, Aug 29, 2013 at 4:35 PM, Zaphod Beeblebrox wrote: > >> So I have a system running: >> >> FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 >> 03:02:55 >> EDT 2013 root@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE i386 >> >> and it has two 2T SATA disks. To keep this post short, the crash.txt is >> here. >> >> >> https://uk.eicat.ca/owncloud/public.php?service=files&t=fea9d25579fe0c4afb808859e80e1493 >> >> now curiously, while running a "make -j4 buildkernel" ... almost every >> time >> ... it crashes with: >> >> g_vfs_done():mirror/walke[WRITE(offset=516764794880, length=65536)]error = >> 11 >> /usr: got error 11 while accessing filesystem >> panic: softdep_deallocate_dependencies: unrecovered I/O error >> >> ... no error report from the hard drives, simply an error report from the >> mirror. >> >> The filesystem is ufs with su+j... but I'm not sure this matters here. >> >> > Run fsck. > > > -- > Adam Vande More > From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 19:36: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A11C8229 for ; Fri, 30 Aug 2013 19:36:24 +0000 (UTC) (envelope-from lausts@acm.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id 63E4B2AA0 for ; Fri, 30 Aug 2013 19:36:24 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=DqnUCRD+ c=1 sm=0 a=DktfseARn6RskVgg/AMIPQ==:17 a=I9A6gpd8bSkA:10 a=kWQ6D_09QQAA:10 a=kHc8Q_KJ-KsA:10 a=N54-gffFAAAA:8 a=KGjhK52YXX0A:10 a=bJVmi5WOh0UA:10 a=7btDH7nx6l41xD86VA0A:9 a=DktfseARn6RskVgg/AMIPQ==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 98.31.3.233 Received: from [98.31.3.233] ([98.31.3.233:46944] helo=mail.laus.org) by hrndva-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 1A/E9-14028-734F0225; Fri, 30 Aug 2013 19:36:23 +0000 Received: from [192.168.1.100] (laust2 [192.168.1.100]) by mail.laus.org (8.14.7/8.14.7) with ESMTP id r7UJaMsN028545 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 30 Aug 2013 15:36:23 -0400 (EDT) (envelope-from lausts@acm.org) X-Authentication-Warning: mail.laus.org: Host laust2 [192.168.1.100] claimed to be [192.168.1.100] From: "Thomas Laus" Organization: ABB To: freebsd-stable@freebsd.org Date: Fri, 30 Aug 2013 15:36:23 -0400 Subject: Lost CAM Access to DVD Writer Message-ID: <5220F437.24888.CC3B3@lausts.acm.org> Priority: normal X-mailer: Pegasus Mail for Windows (4.63) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lausts@acm.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 19:36:24 -0000 I guess this one did not make it back from USENET to gateway I just tried to write to a DVD using both a PC running 9.2-RC3-p0 and 9.2-STABLE r255036 on different computers and get the following error on both computers when a blank is inserted: Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): CAM status: SCSI Status Error Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): SCSI status: Check Condition Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): Error 6, Unretryable error Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): cddone: got error 0x6 back Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): READ(10). CDB: 28 00 00 00 00 00 00 00 01 00 I tried a new DVD drive in both computers. One is a i386 with PATA interface and the other is an AMD with SATA. Both computers have the GENERIC kernel loaded. I also tried using new DVD's of both +R & -R and a CD in the drives with the same result. When I try to write to a DVD or CD, I get the following message: :-( Unable to CAMGETPASSTHRU for /dev/cd0 Inappropriate ioctl for device. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 19:50:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BAA8F56E for ; Fri, 30 Aug 2013 19:50:52 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 492FC2B65 for ; Fri, 30 Aug 2013 19:50:52 +0000 (UTC) Received: by mail-bk0-f47.google.com with SMTP id mx12so824209bkb.20 for ; Fri, 30 Aug 2013 12:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fYBr+RsxNsb7slRHR0U7/axnBTOChRIqUY2AyVTSIJ4=; b=OBSkdqQGVBIi1ay3C+xXq7TpJCEDahnIVsW2UkdhXqheRfpDqWRVgKe4hgnlP3m5R4 FVfisrVPkLj5TbJ1K6c/owJHKa0pVVrkqGPma494aeefLrEX8pjEk2Z8Blw53Ix8jeaH xox1LyVInc197aoyGLGxKrV+tt3IQV6PlZuuvJFd+sOJ/F9ngjgkIL3NJ0Za/JkUISsW KYpphkmaD3wPgJz7ZiNih2M+id4KTzrEsvjv0H6vP1oAIq7pNRptEicVLMxGg1ad/r3t 5GMbY5AtDhvlk/luAyJRoHHD9JYfv5+E3FIO8593QxCwHTbfohMv6E5eYpipOwc/HQNd 5Zcw== X-Received: by 10.204.226.135 with SMTP id iw7mr7766907bkb.4.1377892249174; Fri, 30 Aug 2013 12:50:49 -0700 (PDT) Received: from [192.168.1.102] (addr147.neoplus.adsl.tpnet.pl. [79.184.69.147]) by mx.google.com with ESMTPSA id h5sm8605250bkg.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 12:50:48 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: gmirror crash writing to disk? Or is it su+j crash? From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: Date: Fri, 30 Aug 2013 21:50:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <370A25C8-7747-4B96-A506-EB92FD0F77CF@FreeBSD.org> References: To: Zaphod Beeblebrox X-Mailer: Apple Mail (2.1508) 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: Fri, 30 Aug 2013 19:50:52 -0000 Wiadomo=B6=E6 napisana przez Zaphod Beeblebrox w = dniu 29 sie 2013, o godz. 23:35: > So I have a system running: >=20 > FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 = 03:02:55 > EDT 2013 root@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE i386 >=20 > and it has two 2T SATA disks. To keep this post short, the crash.txt = is > here. >=20 > = https://uk.eicat.ca/owncloud/public.php?service=3Dfiles&t=3Dfea9d25579fe0c= 4afb808859e80e1493 Login error. > now curiously, while running a "make -j4 buildkernel" ... almost every = time > ... it crashes with: >=20 > g_vfs_done():mirror/walke[WRITE(offset=3D516764794880, = length=3D65536)]error =3D > 11 > /usr: got error 11 while accessing filesystem > panic: softdep_deallocate_dependencies: unrecovered I/O error This is softupdates panic caused by write operation returning error 11, = which, according to 'man errno', is EDEADLK. To be honest, I have no idea why gmirror might be returning this error. > ... no error report from the hard drives, simply an error report from = the > mirror. Note that ahci(4) does not log errors unless you're running with = bootverbose. > The filesystem is ufs with su+j... but I'm not sure this matters here. It does, kind of - without soft updates/SUJ, the error would be = non-fatal - it wouldn't panic the box, but it would (probably) cause data corruption. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 20:30:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F17ED568 for ; Fri, 30 Aug 2013 20:30:38 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D3EA62D79 for ; Fri, 30 Aug 2013 20:30:38 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VFVL3-0005m1-9G for freebsd-stable@freebsd.org; Fri, 30 Aug 2013 13:30:37 -0700 Date: Fri, 30 Aug 2013 13:30:37 -0700 (PDT) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1377894637267-5840455.post@n5.nabble.com> In-Reply-To: References: Subject: Re: Some PR never seen to delete MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 20:30:39 -0000 Why would you want to have valid ones closed? -- View this message in context: http://freebsd.1045724.n5.nabble.com/Some-PR-never-seen-to-delete-tp5840405p5840455.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 20:51:42 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 80EAFEEA; Fri, 30 Aug 2013 20:51:42 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 551922EC2; Fri, 30 Aug 2013 20:51:42 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VFVfQ-0004kn-Vi; Fri, 30 Aug 2013 20:51:41 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r7UKpce8057459; Fri, 30 Aug 2013 14:51:38 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+76H6A7DYFlY6oS+0iFUfP Subject: Re: gmirror crash writing to disk? Or is it su+j crash? From: Ian Lepore To: Edward Tomasz =?iso-8859-2?Q?Napiera=B3a?= In-Reply-To: <370A25C8-7747-4B96-A506-EB92FD0F77CF@FreeBSD.org> References: <370A25C8-7747-4B96-A506-EB92FD0F77CF@FreeBSD.org> Content-Type: text/plain; charset="iso-8859-2" Date: Fri, 30 Aug 2013 14:51:38 -0600 Message-ID: <1377895898.1111.341.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id r7UKpce8057459 Cc: Zaphod Beeblebrox , FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 20:51:42 -0000 On Fri, 2013-08-30 at 21:50 +0200, Edward Tomasz Napiera=B3a wrote: > Wiadomo=B6=E6 napisana przez Zaphod Beeblebrox w dn= iu 29 sie 2013, o godz. 23:35: > > So I have a system running: > >=20 > > FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 03= :02:55 > > EDT 2013 root@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE i386 > >=20 > > and it has two 2T SATA disks. To keep this post short, the crash.txt= is > > here. > >=20 > > https://uk.eicat.ca/owncloud/public.php?service=3Dfiles&t=3Dfea9d2557= 9fe0c4afb808859e80e1493 >=20 > Login error. >=20 > > now curiously, while running a "make -j4 buildkernel" ... almost ever= y time > > ... it crashes with: > >=20 > > g_vfs_done():mirror/walke[WRITE(offset=3D516764794880, length=3D65536= )]error =3D > > 11 > > /usr: got error 11 while accessing filesystem > > panic: softdep_deallocate_dependencies: unrecovered I/O error >=20 > This is softupdates panic caused by write operation returning error 11,= which, > according to 'man errno', is EDEADLK. >=20 > To be honest, I have no idea why gmirror might be returning this error. >=20 > > ... no error report from the hard drives, simply an error report from= the > > mirror. >=20 > Note that ahci(4) does not log errors unless you're running with bootve= rbose. >=20 > > The filesystem is ufs with su+j... but I'm not sure this matters here. >=20 > It does, kind of - without soft updates/SUJ, the error would be non-fat= al - it > wouldn't panic the box, but it would (probably) cause data corruption. One of the few places in the kernel that uses EDEADLK is in geom_io.c (line 642 in -current) in g_io_transient_map_bio()... g_io_deliver(bp, EDEADLK/* XXXKIB */); -- Ian From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 22:09: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5731B14B; Fri, 30 Aug 2013 22:09:49 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E474D22D0; Fri, 30 Aug 2013 22:09:48 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id gf11so1649271vcb.25 for ; Fri, 30 Aug 2013 15:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SgV1EjuxCjkiLEB0sKZ8+5Gg4os8L49rH/A8kkgeGtU=; b=XYA2gLnFkg3ps/eFwHeQRaSe3BhqjKokOD0b+hMd1ATX+3mUijVdU6lqOpzkIdr2Dv BjpLthQ8gyMYk8lsB8FcEtkjtd2bI2wu4up4CYVv0bXGoLF3eBoQQ3EUOOMN9PNTET3t C//d/YE6EHW35CuyAkV0x8nvbSeG2Ff6M06IHpeAKCWexTGdq6W7e/t4Jg/3gA7QAwcs mlPT0S2hvNVG7rSAGOA2lQs7K0mJ4xnqbSAHm7mI1jJMMLuLI9xchMMne5/yOA/tBTZ1 qtdTGh8Fp50dnzbdVI66jD4az9nKnt/Ys2xWj110Monrlfafmc2A1kdvnA64jmH9c1Ob P/Bw== MIME-Version: 1.0 X-Received: by 10.221.55.4 with SMTP id vw4mr17642vcb.37.1377900587991; Fri, 30 Aug 2013 15:09:47 -0700 (PDT) Received: by 10.220.122.1 with HTTP; Fri, 30 Aug 2013 15:09:47 -0700 (PDT) In-Reply-To: <1377895898.1111.341.camel@revolution.hippie.lan> References: <370A25C8-7747-4B96-A506-EB92FD0F77CF@FreeBSD.org> <1377895898.1111.341.camel@revolution.hippie.lan> Date: Fri, 30 Aug 2013 18:09:47 -0400 Message-ID: Subject: Re: gmirror crash writing to disk? Or is it su+j crash? From: Zaphod Beeblebrox To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable , =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= 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, 30 Aug 2013 22:09:49 -0000 My bad. New link for the core.txt.4: https://uk.eicat.ca/owncloud/public.php?service=3Dfiles&t=3Df471e5afae48334= 2cd20dc390e9c2dd7 On Fri, Aug 30, 2013 at 4:51 PM, Ian Lepore wrote: > On Fri, 2013-08-30 at 21:50 +0200, Edward Tomasz Napiera=B3a wrote: > > Wiadomo=B6=E6 napisana przez Zaphod Beeblebrox w dn= iu > 29 sie 2013, o godz. 23:35: > > > So I have a system running: > > > > > > FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 > 03:02:55 > > > EDT 2013 root@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE i386 > > > > > > and it has two 2T SATA disks. To keep this post short, the crash.txt > is > > > here. > > > > > > > https://uk.eicat.ca/owncloud/public.php?service=3Dfiles&t=3Dfea9d25579fe0= c4afb808859e80e1493 > > > > Login error. > > > > > now curiously, while running a "make -j4 buildkernel" ... almost ever= y > time > > > ... it crashes with: > > > > > > g_vfs_done():mirror/walke[WRITE(offset=3D516764794880, > length=3D65536)]error =3D > > > 11 > > > /usr: got error 11 while accessing filesystem > > > panic: softdep_deallocate_dependencies: unrecovered I/O error > > > > This is softupdates panic caused by write operation returning error 11, > which, > > according to 'man errno', is EDEADLK. > > > > To be honest, I have no idea why gmirror might be returning this error. > > > > > ... no error report from the hard drives, simply an error report from > the > > > mirror. > > > > Note that ahci(4) does not log errors unless you're running with > bootverbose. > > > > > The filesystem is ufs with su+j... but I'm not sure this matters here= . > > > > It does, kind of - without soft updates/SUJ, the error would be > non-fatal - it > > wouldn't panic the box, but it would (probably) cause data corruption. > > One of the few places in the kernel that uses EDEADLK is in geom_io.c > (line 642 in -current) in g_io_transient_map_bio()... > > g_io_deliver(bp, EDEADLK/* XXXKIB */); > > -- Ian > > > From owner-freebsd-stable@FreeBSD.ORG Fri Aug 30 22:49:35 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 57B17B31; Fri, 30 Aug 2013 22:49:35 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E3F6124AF; Fri, 30 Aug 2013 22:49:34 +0000 (UTC) Received: by mail-ve0-f176.google.com with SMTP id b10so1758749vea.7 for ; Fri, 30 Aug 2013 15:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+Pnx3j+8tWRjEtV42HZJDDTecoCy/+GCjWmPmpx4iSw=; b=QBnlw7TjGo3kFH5XW7kIoAzjwCIaQ+J3xGDaXupuPJW1jpbmB/KTG9UGSU7ydjnbQs JYHCWdCXTvUISAKVR7UG+2hznwF1lnEw+2EylGVVlcXa/IYKGUVMrM8zK2OC7i+um9Im Sc/eO6OpPf/UXFu6UMb4mIKOYTVrmcI2Yvuncl2Gd0+4noLUQkeHKyIxZit4amqjQq70 rxAsy1rApZ+058X92CyXQcvRHKorfnmkUFxw2+suYpeZM3pdtnEufvK2N8AYJRcNwn0h KsokHBMRm6aIgig38efhqzrSYxeMTWCCJy22CgFgsFkgCleQpTZrQ8K/ABa3hqIjn9ra FGIw== MIME-Version: 1.0 X-Received: by 10.52.117.68 with SMTP id kc4mr8007274vdb.0.1377902974054; Fri, 30 Aug 2013 15:49:34 -0700 (PDT) Received: by 10.220.122.1 with HTTP; Fri, 30 Aug 2013 15:49:33 -0700 (PDT) In-Reply-To: References: <370A25C8-7747-4B96-A506-EB92FD0F77CF@FreeBSD.org> <1377895898.1111.341.camel@revolution.hippie.lan> Date: Fri, 30 Aug 2013 18:49:33 -0400 Message-ID: Subject: Re: gmirror crash writing to disk? Or is it su+j crash? From: Zaphod Beeblebrox To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable , =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= 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, 30 Aug 2013 22:49:35 -0000 Because someone said that there would be no logging of unerlying ATA errors without verbose, I rebooted with verbose and tried the same make -j4 again... and here is the relatively similar core.txt.5 https://uk.eicat.ca/owncloud/public.php?service=3Dfiles&t=3Dd99648ef5876b91= c5957148445e60c87 Looking at it, gmirror is dropping the same error and the underlying hardware is not causing the error... On Fri, Aug 30, 2013 at 6:09 PM, Zaphod Beeblebrox wrote= : > My bad. New link for the core.txt.4: > > > https://uk.eicat.ca/owncloud/public.php?service=3Dfiles&t=3Df471e5afae483= 342cd20dc390e9c2dd7 > > > > > On Fri, Aug 30, 2013 at 4:51 PM, Ian Lepore wrote: > >> On Fri, 2013-08-30 at 21:50 +0200, Edward Tomasz Napiera=B3a wrote: >> > Wiadomo=B6=E6 napisana przez Zaphod Beeblebrox w d= niu >> 29 sie 2013, o godz. 23:35: >> > > So I have a system running: >> > > >> > > FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 >> 03:02:55 >> > > EDT 2013 root@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE i386 >> > > >> > > and it has two 2T SATA disks. To keep this post short, the crash.tx= t >> is >> > > here. >> > > >> > > >> https://uk.eicat.ca/owncloud/public.php?service=3Dfiles&t=3Dfea9d25579fe= 0c4afb808859e80e1493 >> > >> > Login error. >> > >> > > now curiously, while running a "make -j4 buildkernel" ... almost >> every time >> > > ... it crashes with: >> > > >> > > g_vfs_done():mirror/walke[WRITE(offset=3D516764794880, >> length=3D65536)]error =3D >> > > 11 >> > > /usr: got error 11 while accessing filesystem >> > > panic: softdep_deallocate_dependencies: unrecovered I/O error >> > >> > This is softupdates panic caused by write operation returning error 11= , >> which, >> > according to 'man errno', is EDEADLK. >> > >> > To be honest, I have no idea why gmirror might be returning this error= . >> > >> > > ... no error report from the hard drives, simply an error report fro= m >> the >> > > mirror. >> > >> > Note that ahci(4) does not log errors unless you're running with >> bootverbose. >> > >> > > The filesystem is ufs with su+j... but I'm not sure this matters her= e. >> > >> > It does, kind of - without soft updates/SUJ, the error would be >> non-fatal - it >> > wouldn't panic the box, but it would (probably) cause data corruption. >> >> One of the few places in the kernel that uses EDEADLK is in geom_io.c >> (line 642 in -current) in g_io_transient_map_bio()... >> >> g_io_deliver(bp, EDEADLK/* XXXKIB */); >> >> -- Ian >> >> >> > From owner-freebsd-stable@FreeBSD.ORG Sat Aug 31 05:47:15 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3739DDDF for ; Sat, 31 Aug 2013 05:47:15 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 83FFD2ADA for ; Sat, 31 Aug 2013 05:47:10 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id r7V5kWOx095054; Fri, 30 Aug 2013 23:46:33 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id r7V5kUK2095053; Fri, 30 Aug 2013 23:46:30 -0600 (MDT) (envelope-from ken) Date: Fri, 30 Aug 2013 23:46:30 -0600 From: "Kenneth D. Merry" To: Thomas Laus Subject: Re: Lost CAM Access to DVD Writer Message-ID: <20130831054630.GA95009@nargothrond.kdm.org> References: <5220F437.24888.CC3B3@lausts.acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5220F437.24888.CC3B3@lausts.acm.org> User-Agent: Mutt/1.4.2i 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, 31 Aug 2013 05:47:15 -0000 On Fri, Aug 30, 2013 at 15:36:23 -0400, Thomas Laus wrote: > I guess this one did not make it back from USENET to gateway > > I just tried to write to a DVD using both a PC running 9.2-RC3-p0 and > 9.2-STABLE r255036 on different computers and get the following error > on both computers when a blank is inserted: > > Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): CAM status: SCSI Status Error > Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): SCSI status: Check Condition > Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): SCSI sense: ILLEGAL REQUEST > asc:64,0 (Illegal mode for this track) > Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): Error 6, Unretryable error > Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): cddone: got error 0x6 back > Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): READ(10). CDB: 28 00 00 00 00 > 00 00 00 01 00 > > I tried a new DVD drive in both computers. One is a i386 with PATA > interface and the other is an AMD with SATA. Both computers have the > GENERIC kernel loaded. I also tried using new DVD's of both +R & -R > and a CD in the drives with the same result. > > When I try to write to a DVD or CD, I get the following message: > > :-( Unable to CAMGETPASSTHRU for /dev/cd0 Inappropriate ioctl for device. You probably need to recompile whatever application you're using to burn CDs. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-stable@FreeBSD.ORG Sat Aug 31 09:27:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 85A417FC; Sat, 31 Aug 2013 09:27:19 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DBEB225A0; Sat, 31 Aug 2013 09:27:18 +0000 (UTC) Received: by mail-bk0-f51.google.com with SMTP id mx10so994645bkb.10 for ; Sat, 31 Aug 2013 02:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CvQhmtEWBBHmd7iZIkMXYXSwlrX+AL7eMc1kjFbebEY=; b=jOsBwmNN8UB4N8yn/W9wPVza/Cipg6O1yJbLJDYfcAZMcfidxxgc7TZM+fS0UoPmGZ t02doXt0khw2ZPe1W6JmVVfaL1WUAFXOeSAYaT5VwnvBi/w4K/8oWCTnf+CHoCeYAS6X Bqod87VQEebfrDsMaQ5LoCSFNi73BxNRJ0Aq5huYEtpd5jzDxFtiGIPGfHSID2xd7KAX X4zQiV07NTnzZTwjW0zP9Qr7mzjRMP6cirvexjhEpElaFgvKwP4KAxQc2Th0ScgfD9pc MRoALKgebXq8KJCESLR28mUSVOgOci9/7KdXkNxJqNIWQbwf6uH5+ccotyGDLTsQEy10 G16w== X-Received: by 10.204.224.142 with SMTP id io14mr482454bkb.27.1377941236130; Sat, 31 Aug 2013 02:27:16 -0700 (PDT) Received: from [192.168.1.102] (addr147.neoplus.adsl.tpnet.pl. [79.184.69.147]) by mx.google.com with ESMTPSA id nv4sm260411bkb.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 Aug 2013 02:27:15 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: gmirror crash writing to disk? Or is it su+j crash? From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: Date: Sat, 31 Aug 2013 11:27:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <370A25C8-7747-4B96-A506-EB92FD0F77CF@FreeBSD.org> <1377895898.1111.341.camel@revolution.hippie.lan> To: Zaphod Beeblebrox X-Mailer: Apple Mail (2.1508) Cc: FreeBSD Stable , Ian Lepore X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 09:27:19 -0000 Wiadomo=B6=E6 napisana przez Zaphod Beeblebrox w = dniu 31 sie 2013, o godz. 00:49: > Because someone said that there would be no logging of unerlying ATA = errors without verbose, I rebooted with verbose and tried the same make = -j4 again... and here is the relatively similar core.txt.5 >=20 > = https://uk.eicat.ca/owncloud/public.php?service=3Dfiles&t=3Dd99648ef5876b9= 1c5957148445e60c87 >=20 > Looking at it, gmirror is dropping the same error and the underlying = hardware is not causing the error... Let me quote Konstantin: > It is either an exhaustion of the transient map, or a deadlock. > For the first, setting kern.geom.transient_map_retries to 0 could = help. > For the second, the count of the transient buffers must be increased, > by kern.bio_transient_maxcnt loader tunable. Could you try both and tell which one of them fixed the problem? = Thanks! From owner-freebsd-stable@FreeBSD.ORG Sat Aug 31 13:00:06 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2564A2D3; Sat, 31 Aug 2013 13:00:06 +0000 (UTC) (envelope-from lausts@acm.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id C969D2FE8; Sat, 31 Aug 2013 13:00:05 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=fJG7LOme c=1 sm=0 a=DktfseARn6RskVgg/AMIPQ==:17 a=I9A6gpd8bSkA:10 a=cJzkC_CqN18A:10 a=kWQ6D_09QQAA:10 a=kHc8Q_KJ-KsA:10 a=N54-gffFAAAA:8 a=KGjhK52YXX0A:10 a=-mWxnwzdiyYA:10 a=RE0XfHyR56E_BtozBDgA:9 a=DktfseARn6RskVgg/AMIPQ==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 98.31.3.233 Received: from [98.31.3.233] ([98.31.3.233:61474] helo=mail.laus.org) by hrndva-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 2A/E5-27973-FC8E1225; Sat, 31 Aug 2013 12:59:59 +0000 Received: from [192.168.1.100] (laust2 [192.168.1.100]) by mail.laus.org (8.14.7/8.14.7) with ESMTP id r7VCxwWt030683 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Sat, 31 Aug 2013 08:59:58 -0400 (EDT) (envelope-from lausts@acm.org) X-Authentication-Warning: mail.laus.org: Host laust2 [192.168.1.100] claimed to be [192.168.1.100] From: "Thomas Laus" Organization: ABB To: "Kenneth D. Merry" , freebsd-stable@freebsd.org Date: Sat, 31 Aug 2013 09:00:09 -0400 Subject: Re: Lost CAM Access to DVD Writer Message-ID: <5221E8D9.31243.A1126@lausts.acm.org> Priority: normal In-reply-to: <20130831054630.GA95009@nargothrond.kdm.org> References: <5220F437.24888.CC3B3@lausts.acm.org>, <20130831054630.GA95009@nargothrond.kdm.org> X-mailer: Pegasus Mail for Windows (4.63) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lausts@acm.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2013 13:00:06 -0000 > You probably need to recompile whatever application you're using to burn > CDs. > The actual program, cdrecord, works when invoked from the command line. The following script does not: EXAMPLES Dumps the /u file system to DVDs using growisofs. Uses a 16MB cache, creates a snapshot of the dump, and records the dumpdates file. /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u I wonder if the recent change to devfs might be the root cause of my problem. I have been dumping to DVD for years without any issues until now. Maybe the re-direction to /dev/fd/0 requires a different syntax. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-stable@FreeBSD.ORG Sat Aug 31 13:40:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DF229FBF; Sat, 31 Aug 2013 13:40:24 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 94AEF227F; Sat, 31 Aug 2013 13:40:24 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VFlRc-000FgY-Ux; Sat, 31 Aug 2013 17:42:28 +0400 Date: Sat, 31 Aug 2013 17:42:28 +0400 From: Slawa Olhovchenkov To: Thomas Laus Subject: Re: Lost CAM Access to DVD Writer Message-ID: <20130831134228.GA59931@zxy.spb.ru> References: <5220F437.24888.CC3B3@lausts.acm.org> <20130831054630.GA95009@nargothrond.kdm.org> <5221E8D9.31243.A1126@lausts.acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5221E8D9.31243.A1126@lausts.acm.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org, "Kenneth D. Merry" 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, 31 Aug 2013 13:40:24 -0000 On Sat, Aug 31, 2013 at 09:00:09AM -0400, Thomas Laus wrote: > > You probably need to recompile whatever application you're using to burn > > CDs. > > > The actual program, cdrecord, works when invoked from the command line. The > following script does not: > > EXAMPLES > Dumps the /u file system to DVDs using growisofs. Uses a 16MB cache, > creates a snapshot of the dump, and records the dumpdates file. > > /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u > > I wonder if the recent change to devfs might be the root cause of my problem. > I have been dumping to DVD for years without any issues until now. Maybe the > re-direction to /dev/fd/0 requires a different syntax. Are you sure mount fdescfs? /dev/fd is fdescfs, not devfs. From owner-freebsd-stable@FreeBSD.ORG Sat Aug 31 13:44:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EDECD23D; Sat, 31 Aug 2013 13:44:00 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7644422C0; Sat, 31 Aug 2013 13:43:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id r7VDhsfA059964; Sat, 31 Aug 2013 17:43:54 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Sat, 31 Aug 2013 17:43:54 +0400 (MSK) From: Dmitry Morozovsky To: Slawa Olhovchenkov Subject: Re: Lost CAM Access to DVD Writer In-Reply-To: <20130831134228.GA59931@zxy.spb.ru> Message-ID: References: <5220F437.24888.CC3B3@lausts.acm.org> <20130831054630.GA95009@nargothrond.kdm.org> <5221E8D9.31243.A1126@lausts.acm.org> <20130831134228.GA59931@zxy.spb.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Sat, 31 Aug 2013 17:43:54 +0400 (MSK) Cc: "Kenneth D. Merry" , freebsd-stable@freebsd.org, Thomas Laus 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, 31 Aug 2013 13:44:01 -0000 On Sat, 31 Aug 2013, Slawa Olhovchenkov wrote: > > > You probably need to recompile whatever application you're using to burn > > > CDs. > > > > > The actual program, cdrecord, works when invoked from the command line. The > > following script does not: > > > > EXAMPLES > > Dumps the /u file system to DVDs using growisofs. Uses a 16MB cache, > > creates a snapshot of the dump, and records the dumpdates file. > > > > /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u > > > > I wonder if the recent change to devfs might be the root cause of my problem. > > I have been dumping to DVD for years without any issues until now. Maybe the > > re-direction to /dev/fd/0 requires a different syntax. > > Are you sure mount fdescfs? /dev/fd is fdescfs, not devfs. Are you sure? At least, std* are there even if fdescfs is absent: marck@castor:/FreeBSD/rinet/src.9/sys> kldstat -v | grep fdesc marck@castor:/FreeBSD/rinet/src.9/sys> ls /dev/fd 0 1 2 -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Sat Aug 31 13:52:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D12123AF; Sat, 31 Aug 2013 13:52:04 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 87DEB231F; Sat, 31 Aug 2013 13:52:04 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VFlct-000Fl0-Ng; Sat, 31 Aug 2013 17:54:07 +0400 Date: Sat, 31 Aug 2013 17:54:07 +0400 From: Slawa Olhovchenkov To: Dmitry Morozovsky Subject: Re: Lost CAM Access to DVD Writer Message-ID: <20130831135407.GB3796@zxy.spb.ru> References: <5220F437.24888.CC3B3@lausts.acm.org> <20130831054630.GA95009@nargothrond.kdm.org> <5221E8D9.31243.A1126@lausts.acm.org> <20130831134228.GA59931@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: "Kenneth D. Merry" , freebsd-stable@freebsd.org, Thomas Laus 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, 31 Aug 2013 13:52:04 -0000 On Sat, Aug 31, 2013 at 05:43:54PM +0400, Dmitry Morozovsky wrote: > On Sat, 31 Aug 2013, Slawa Olhovchenkov wrote: > > > > > You probably need to recompile whatever application you're using to burn > > > > CDs. > > > > > > > The actual program, cdrecord, works when invoked from the command line. The > > > following script does not: > > > > > > EXAMPLES > > > Dumps the /u file system to DVDs using growisofs. Uses a 16MB cache, > > > creates a snapshot of the dump, and records the dumpdates file. > > > > > > /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u > > > > > > I wonder if the recent change to devfs might be the root cause of my problem. > > > I have been dumping to DVD for years without any issues until now. Maybe the > > > re-direction to /dev/fd/0 requires a different syntax. > > > > Are you sure mount fdescfs? /dev/fd is fdescfs, not devfs. > > Are you sure? At least, std* are there even if fdescfs is absent: > > marck@castor:/FreeBSD/rinet/src.9/sys> kldstat -v | grep fdesc > marck@castor:/FreeBSD/rinet/src.9/sys> ls /dev/fd > 0 1 2 > ls /dev/fd/ 0 1 2 3 4 Hmm, w/o fdescfs only std*. With fdescfs more. From owner-freebsd-stable@FreeBSD.ORG Sat Aug 31 17:35:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 18C6BA59; Sat, 31 Aug 2013 17:35:23 +0000 (UTC) (envelope-from mvharding@gmail.com) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5242E2C76; Sat, 31 Aug 2013 17:35:22 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id hi5so528799wib.10 for ; Sat, 31 Aug 2013 10:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/mGNXIYobu22sasCEgI6NdqA+YWgXcxQ6020YWb4r6g=; b=Glo++VZwdvS46ozW3qE3TQ6lHvXtwNMaTwFkaojiQWSbJ9HeTy0nyedB1LNIOkRhwU GrJ3MP9oJDQHe9zAs83UnPqGwmoQ8ROyDpV4EUz74+hcsjNE5EHb2l3+cCHmjxbJNVgT TLkKdvNwSIoYLIgNoQUjkX3YtVa1KvwNj34mCggSJHTmpv65DV2cczFuWEmKEBAEXt5h siBQ9cmouasSMyQJo3fFgTQmvs7aq36Wa+RAzhz5r3+/nx3m3MQpj8C7NPrWW9VzB7Rh G/QUyFpZMnx3XxjgMxqK8D6ZAybQtcpxcuqecRSvglW+8BPVbcWAP2sNSWeEe2NMgO1z BwEA== MIME-Version: 1.0 X-Received: by 10.180.72.47 with SMTP id a15mr6965094wiv.63.1377970520568; Sat, 31 Aug 2013 10:35:20 -0700 (PDT) Received: by 10.217.67.69 with HTTP; Sat, 31 Aug 2013 10:35:20 -0700 (PDT) In-Reply-To: References: Date: Sat, 31 Aug 2013 10:35:20 -0700 Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Mike Harding To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List 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, 31 Aug 2013 17:35:23 -0000 I've tracked this down to a single line, details in http://www.freebsd.org/cgi/query-pr.cgi?pr=181632. Basically, the code is now doing a 'sti, hlt' vs. a 'sti' in some code that is only supposed to run if idle is disabled. Given that 'hlt' is the idle instruction, this doesn't seem right. On Thu, Aug 29, 2013 at 11:50 PM, Adrian Chadd wrote: > On 29 August 2013 23:46, Mike Harding wrote: > >> I was able to track this down by building kernels against /base/stable/9 >> (it took >> -hours!-). >> > > Wow, thanks! > > >> The issue does occur with commit 244616, but does not occur with 244614. >> The >> only difference is a small patch to /usr/src/sys/dev/acpica/acpi_cpu.c - >> this >> code appears to do with c-state processing. I'll note it in the ticket, >> but somebody >> might want to look at this ASAP >> > > That's awesome. It's a very small ACPI patch. Let's see if the others who > are having this issue can test this out and report back! > > Thanks! > > > > -adrian > > From owner-freebsd-stable@FreeBSD.ORG Sat Aug 31 19:49:54 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1B8544C4; Sat, 31 Aug 2013 19:49:54 +0000 (UTC) (envelope-from tdb@carrick.bishnet.net) Received: from carrick.bishnet.net (carrick-mx.bishnet.net [IPv6:2a01:348:132:51::14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D30802199; Sat, 31 Aug 2013 19:49:53 +0000 (UTC) Received: from carrick-users.bishnet.net ([2a01:348:132:51::10]) by carrick.bishnet.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VFrB9-000El4-WB; Sat, 31 Aug 2013 20:49:52 +0100 Received: (from tdb@localhost) by carrick-users.bishnet.net (8.14.7/8.14.7/Submit) id r7VJnprS056733; Sat, 31 Aug 2013 20:49:51 +0100 (BST) (envelope-from tdb) Date: Sat, 31 Aug 2013 20:49:51 +0100 From: Tim Bishop To: freebsd-stable@FreeBSD.org, freebsd-pf@FreeBSD.org Subject: Stiil a regression with jails/IPv6/pf? Message-ID: <20130831194951.GC44979@carrick-users.bishnet.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline X-PGP-Key: 0x6C226B37FDF38D55, http://www.bishnet.net/tim/tim-bishnet-net.asc X-PGP-Fingerprint: 4BD9 5F90 8A50 40E8 D26C D681 6C22 6B37 FDF3 8D55 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: bz@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, 31 Aug 2013 19:49:54 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, This is regarding kern/170070 and these two threads from last year: http://lists.freebsd.org/pipermail/freebsd-stable/2012-July/068987.html http://lists.freebsd.org/pipermail/freebsd-stable/2012-August/069043.html I'm running stable/9 r255017 and I'm seeing the same issue, even with the fix Bjoern committed in r238876. My setup is a dual stack one (IPv6 is done through an IPv4 tunnel) and the problem is only with IPv6. I have jails with both IPv4 and IPv6 addresses, and I use pf to rdr certain ports to certain jails. With IPv6 I'm seeing failed checksums on the packets coming back out of my system, both with UDP and TCP. If I connect over IPv6 to the jail host it works fine. If I connect over IPv6 to a jail directly (they have routable addresses, but I prefer them to all be masked behind the single jail host normally), it works fine. So the only failure case is when it goes through a rdr rule in pf. This system replaces a previous one running stable/8 which worked fine with the same pf config file. Has anyone got any suggestions on what I can do to fix this or to debug it further? Thanks, Tim. --=20 Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x6C226B37FDF38D55 --jRHKVT23PllUwdXP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQIcBAEBCgAGBQJSIkjfAAoJEGwiazf9841V/0EP/3FswICXwY8PbrlrNd+IUQkO I9nfgGJOl7M9ET7vT7w1OY8WnH8/LFl/Tqy45DJdkQQZd3ZgEx93MPWCR7ItCIqV pjz3Fn+GVkBlOtJ0oro//X01mUy0j5MvFqbaUEnnPU47ohaJPi7++kRQz9quW++j sncs9EYlO4M9I13/TUJbfF5nthxv7UN6qM0lUIX52Gl4qN1VIV576fy/kMdjC+Z/ 8l4D7bmWirljmISD0LrQsc3pqV66Up9huuxYR/ofiZb/oUFCIzEYuutjYyCcOyRI k47nMWLFxLgjQiPpWv53mMZX6KUzI4sfQHULQkekFt6UDe4D2WPZafMS16DgrG4j yBjQvceqiX30lkZNC/CzAQoPZoh39xATeYMonuCsW+rLjb5EqZvyhAObVKC+j45q 8EySdAgkogz4gyqp+M+flfUkc6G2RteE2oz1UZjXH7KakEaOdDG4SWtjotrpO+m+ M1R4vZfO6ZbBNA3ilywjx+f/oGTyIkRSPo87aN66S7RQxpAfrA6oyzhWyPfLkl3a KDsM3/tUMreexEqnbCKsSx3m7WAAnEQEPW5Hecg8eo3SlkkgvMGYEn9mpLBcGxl1 Q7C+q6oSuRyNVOvleTyLOQj5rw7LF2NzwXSNb27/VaUinc8UeylAqfL38ZBRrV4l x/o5uH+QSrd0RPOTI0NW =Ogos -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From owner-freebsd-stable@FreeBSD.ORG Sat Aug 31 23:40:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 197C6F50; Sat, 31 Aug 2013 23:40:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 51A9C2A16; Sat, 31 Aug 2013 23:40:57 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id m14so833690wgh.7 for ; Sat, 31 Aug 2013 16:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DrdHgXWOZ9F3Myz6zWtP6fEn74TEhKzWOIRz5vhXXBs=; b=dixizIhljWoMqTyr96THI/o4h1pGvtowzJjQLtVbOvgzXP2s8ZWq+2EhYICO5W9fKs jShS8NmWQmUCWMx93kF4KwuxyDa8qVhGvDOycrAYDNErtzpLSzQoD9MhnmtqJOTHIRqh g7wnjxi53PSXAHGGDAKDhuYVlFdJQnvc3j9vhc6LDHVYMiZaooDFOuZY8EEnSypDYVYV i/5QjVAQmw7s6CWK7eHYU9DFFG49whs7YiVL+y2/I0n8h9cX5H6w1/ZS8BZ79aHVAwuP aMTLAEqaPyMdz1hXXDU5L4fRp6Zb6m+chHZeIi6YYhBS/dgTEGhXT75hOtj5R6vfOUcj iglQ== MIME-Version: 1.0 X-Received: by 10.194.8.9 with SMTP id n9mr16913207wja.11.1377992455156; Sat, 31 Aug 2013 16:40:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.146.2 with HTTP; Sat, 31 Aug 2013 16:40:55 -0700 (PDT) In-Reply-To: References: Date: Sat, 31 Aug 2013 16:40:55 -0700 X-Google-Sender-Auth: Y1WPSbNHgATSkJkUBccuulVU5qY Message-ID: Subject: Re: 9.2-RC3 - suspend/resume causes slow system performance From: Adrian Chadd To: Mike Harding , Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-acpi@freebsd.org" , FreeBSD Stable Mailing List 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, 31 Aug 2013 23:40:58 -0000 On 31 August 2013 10:35, Mike Harding wrote: > I've tracked this down to a single line, details in > http://www.freebsd.org/cgi/query-pr.cgi?pr=181632. Basically, the code > is now doing a 'sti, hlt' vs. a 'sti' in some code that is only supposed to > run if idle is disabled. Given that 'hlt' is the idle instruction, this > doesn't seem right. > > Wow, nice! Avg - can we get this fixed? Or just revert this! -adrian