From owner-freebsd-stable@FreeBSD.ORG Sun Feb 10 02:41:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 68E01BDE for ; Sun, 10 Feb 2013 02:41:39 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 003C03A5 for ; Sun, 10 Feb 2013 02:41:38 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r1A2fb9F053132 for ; Sat, 9 Feb 2013 21:41:37 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id r1A2fb6t053129; Sat, 9 Feb 2013 21:41:37 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20759.2273.284868.12857@hergotha.csail.mit.edu> Date: Sat, 9 Feb 2013 21:41:37 -0500 From: Garrett Wollman To: freebsd-stable@freebsd.org Subject: Interpreting "vmstat -z" output X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Sat, 09 Feb 2013 21:41:37 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Feb 2013 02:41:39 -0000 On a server that's been experiencing some issues, I note the following in "vmstat -z": ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 188, 16, 188, 0, 0 UMA Zones: 3456, 0, 188, 0, 188, 0, 0 UMA Slabs: 568, 0, 1209668, 6211,50929964, 0, 0 UMA RCntSlabs: 568, 0, 50791, 1, 50791, 0, 0 UMA Hash: 256, 0, 78, 12, 80, 0, 0 16 Bucket: 152, 0, 227, 23, 227, 0, 0 32 Bucket: 280, 0, 522, 10, 522, 0, 0 64 Bucket: 536, 0, 783, 1, 783, 156, 0 128 Bucket: 1048, 0, 33513, 0, 33513,134423, 0 [...] How should I interpret the failure count for "64 Bucket" and "128 Bucket"? Does it represent a problem, or something that needs to be tuned? There are no obvious tunables, but the code is not exactly transparent. No other zones show failures. -GAWollman From owner-freebsd-stable@FreeBSD.ORG Sun Feb 10 05:29:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 63350AFD; Sun, 10 Feb 2013 05:29:40 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 1F5999C6; Sun, 10 Feb 2013 05:29:40 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.189]) by hub.org (Postfix) with ESMTP id 3D4431B9C781; Sun, 10 Feb 2013 01:29:33 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.189]) (amavisd-maia, port 10024) with ESMTP id 26368-05; Sun, 10 Feb 2013 05:29:32 +0000 (UTC) Received: from [192.168.0.52] (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id 4AE9B1B9C780; Sun, 10 Feb 2013 01:29:32 -0400 (AST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 9-STABLE -> NFS -> NetAPP: From: Marc Fournier In-Reply-To: <201301190757.26398.jhb@freebsd.org> Date: Sat, 9 Feb 2013 21:29:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <461A7DB1-4693-4AA5-B43C-5F15FE0C4918@hub.org> References: <201301190757.26398.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1499) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 05:29:40 -0000 Hi John =85 Does this help? root@io:~ # ps auxl | grep du root 1054 0.0 0.1 16176 6600 ?? D 3:15AM 0:05.38 du = -skx /vm/2799 0 81426 0 20 0 newnfs root 12353 0.0 0.1 16176 5104 ?? D Sat03AM 0:05.41 du = -skx /vm/2799 0 91597 0 20 0 newnfs root 64529 0.0 0.1 16176 5164 ?? D Fri03AM 0:05.40 du = -skx /vm/2799 0 43227 0 20 0 newnfs root 12855 0.0 0.0 16308 1988 0 S+ 5:26AM 0:00.00 grep = du 0 12847 0 20 0 piperd root@io:~ # grep vm /etc/fstab 192.168.1.254:/vol/basic /vm nfs rw,nolockd,intr 0 = 0 Haven't rebooted yet =85 if there is anything I can do / try before =85 = ? The kernel is from Jan 21st =85 On 2013-01-19, at 4:57 AM, John Baldwin wrote: > On Tuesday, December 18, 2012 11:58:36 PM Hub- Marketing wrote: >> I'm running a few servers sitting on top of a NetAPP file server =85 >> everything runs great, but periodically I'm getting: >>=20 >> nfs_getpages: error 13 >> vm_fault: pager read error, pid 11355 (https) >=20 > Are you using interruptible mounts ("intr" mount option)? >=20 > Also, can you get ps output that includes the 'l' flag to show what > the processes are stuck on? >=20 > --=20 > John Baldwin From owner-freebsd-stable@FreeBSD.ORG Sun Feb 10 06:06:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2D8EBE92; Sun, 10 Feb 2013 06:06:13 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id EF789A82; Sun, 10 Feb 2013 06:06:12 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.188]) by hub.org (Postfix) with ESMTP id EC6011B9C781; Sun, 10 Feb 2013 02:06:11 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.188]) (amavisd-maia, port 10024) with ESMTP id 50057-09; Sun, 10 Feb 2013 06:06:11 +0000 (UTC) Received: from [192.168.0.52] (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id BD0AA1B9C780; Sun, 10 Feb 2013 02:06:10 -0400 (AST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 9-STABLE -> NFS -> NetAPP: From: Marc Fournier In-Reply-To: <20130210055856.GA78494@icarus.home.lan> Date: Sat, 9 Feb 2013 22:06:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7E5C346B-A8A1-4F2F-B768-9492D7B633BF@hub.org> References: <201301190757.26398.jhb@freebsd.org> <461A7DB1-4693-4AA5-B43C-5F15FE0C4918@hub.org> <20130210055856.GA78494@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1499) Cc: "freebsd-stable@freebsd.org" , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 06:06:13 -0000 Thanks =85 # procstat -kk 64529 PID TID COMM TDNAME KSTACK = =20 64529 100963 du - mi_switch+0x186 = sleepq_wait+0x42 __lockmgr_args+0x5cb nfs_lock1+0x4a VOP_LOCK1_APV+0x46 = _vn_lock+0x47 vget+0x70 cache_lookup_times+0x54f nfs_lookup+0x17e = lookup+0x42f namei+0x4ac vn_open_cred+0x3bd kern_openat+0x20a = amd64_syscall+0x540 Xfast_syscall+0xf7 On 2013-02-09, at 9:58 PM, Jeremy Chadwick wrote: > Off-list: >=20 > Marc, >=20 > You may want to also provide output from "procstat -kk 64529", as this > will give a full thread calling stack. >=20 > The -kk (double-kay) is not a typo. :-) >=20 > --=20 > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Mountain View, CA, US | > | Making life hard for others since 1977. PGP 4BD6C0CB | >=20 > On Sat, Feb 09, 2013 at 09:29:30PM -0800, Marc Fournier wrote: >>=20 >> Hi John ? >>=20 >> Does this help? >>=20 >> root@io:~ # ps auxl | grep du >> root 1054 0.0 0.1 16176 6600 ?? D 3:15AM 0:05.38 du = -skx /vm/2799 0 81426 0 20 0 newnfs >> root 12353 0.0 0.1 16176 5104 ?? D Sat03AM 0:05.41 du = -skx /vm/2799 0 91597 0 20 0 newnfs >> root 64529 0.0 0.1 16176 5164 ?? D Fri03AM 0:05.40 du = -skx /vm/2799 0 43227 0 20 0 newnfs >> root 12855 0.0 0.0 16308 1988 0 S+ 5:26AM 0:00.00 = grep du 0 12847 0 20 0 piperd >> root@io:~ # grep vm /etc/fstab >> 192.168.1.254:/vol/basic /vm nfs rw,nolockd,intr 0 = 0 >>=20 >> Haven't rebooted yet ? if there is anything I can do / try before ? ? >>=20 >> The kernel is from Jan 21st ? >>=20 >>=20 >> On 2013-01-19, at 4:57 AM, John Baldwin wrote: >>=20 >>> On Tuesday, December 18, 2012 11:58:36 PM Hub- Marketing wrote: >>>> I'm running a few servers sitting on top of a NetAPP file server ? >>>> everything runs great, but periodically I'm getting: >>>>=20 >>>> nfs_getpages: error 13 >>>> vm_fault: pager read error, pid 11355 (https) >>>=20 >>> Are you using interruptible mounts ("intr" mount option)? >>>=20 >>> Also, can you get ps output that includes the 'l' flag to show what >>> the processes are stuck on? >>>=20 >>> --=20 >>> John Baldwin >>=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" From owner-freebsd-stable@FreeBSD.ORG Sun Feb 10 10:58:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E6C8097B; Sun, 10 Feb 2013 10:58:28 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id CA77363C; Sun, 10 Feb 2013 10:58:28 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 483DE6003; Sun, 10 Feb 2013 04:58:22 -0600 (CST) Date: Sun, 10 Feb 2013 04:58:22 -0600 From: Mark Linimon To: Dimitry Andric , Kimmo Paasiala , freebsd-stable@freebsd.org, FreeBSD current Subject: Re: CLANG and -fstack-protector Message-ID: <20130210105822.GA2944@lonesome.com> References: <51141769.5060905@FreeBSD.org> <20130207225242.GA5900@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130207225242.GA5900@felucia.tataz.chchile.org> User-Agent: Mutt/1.5.20 (2009-06-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: Sun, 10 Feb 2013 10:58:29 -0000 On Thu, Feb 07, 2013 at 11:52:42PM +0100, Jeremie Le Hen wrote: > You can do this, it will work for most of the ports but some ports do > not honor CFLAGS. Ports that don't honor CFLAGS are broken ports. Having said that, the last time I ran a script that looked for them (and other things like CXXFLAGS), the results were really disappointing. This would be a good project for someone to take on. OTOH this reply is probably more appropriate for ports@. mcl From owner-freebsd-stable@FreeBSD.ORG Sun Feb 10 11:54:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B1369F57 for ; Sun, 10 Feb 2013 11:54:46 +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 5FFE38B4 for ; Sun, 10 Feb 2013 11:54:45 +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 9F6608618F for ; Sun, 10 Feb 2013 12:54:37 +0100 (CET) Message-ID: <51178A7C.9000700@bsdforen.de> Date: Sun, 10 Feb 2013 12:54:36 +0100 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130129 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: stable/9 Xorg freezes and hangs in drmlk2 X-Enigmail-Version: 1.4.6 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, 10 Feb 2013 11:54:46 -0000 Occasionally Xorg freezes and hangs in state drmlk2, when I start the compositing manager or an overlay window (i.e. mplayer) opens. The last time that happened (starting the compositor) I ssh'ed into the box and collected some data. > uname -a > pkg_info -Ex xorg > pkg_info -Ex xf86 > top -PCS > tail /var/log/Xorg.0.log > tail -n2 ~user/.xsession-errors > pciconf -lv http://pastebin.com/ExgFDKZ8 The Xorg.0.log: http://pastebin.com/gGubtXqk Last line states: [mi] EQ overflowing. The server is probably stuck in an infinite loop. The Xorg process does not react to SIGTERM in this state. This time when I sent it a SIGKILL it miraculously restarted just fine. I'm even using the compositor that right now! Usually xdm goes into a loop trying to start Xorg and Xorg crashing because of some video driver mumbo jumbo that I cannot tell you about, because it didn't happen this time. One last thing, I'm using e17's OpenGL compositing and when it's turned on starting mplayer is much more likely to freeze Xorg (but the last time mplayer froze it, the compositor wasn't on). It usually takes a couple of hours of runtime before there is significant likeliness of this happening. I sometimes have days of runtime without incident, though. Regards -- 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 Feb 10 12:31:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5688F8D2 for ; Sun, 10 Feb 2013 12:31:23 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) by mx1.freebsd.org (Postfix) with ESMTP id DDE53A49 for ; Sun, 10 Feb 2013 12:31:22 +0000 (UTC) Received: from [78.35.179.134] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1U4W3v-0003fV-DG; Sun, 10 Feb 2013 13:31:15 +0100 Date: Sun, 10 Feb 2013 13:31:10 +0100 From: Fabian Keil To: Jeremy Chadwick Subject: Re: patch which implements ZFS LZ4 compression Message-ID: <20130210133110.1a5a3ca0@fabiankeil.de> In-Reply-To: <20130209204436.GA67890@icarus.home.lan> References: <511581C9.5040608@delphij.net> <20130208230830.GA45081@icarus.home.lan> <20130209151918.221176cd@fabiankeil.de> <20130209204436.GA67890@icarus.home.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_//+Dl4ssRW1LsCxzojoB9S8J"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 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, 10 Feb 2013 12:31:23 -0000 --Sig_//+Dl4ssRW1LsCxzojoB9S8J Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Jeremy Chadwick wrote: > On Sat, Feb 09, 2013 at 03:19:18PM +0100, Fabian Keil wrote: > > Jeremy Chadwick wrote: =20 > > > If you want a PR for it, I'll file one, but all it's going to contain= is > > > the contents of this Email. > >=20 > > My impression is that your emails describe symptoms and contain > > some speculation about what the cause might be. I didn't see any > > sched traces, so it's unclear (to me) that priorities are actual > > the problem. >=20 > They contain no speculation. >=20 > Bob Friesenhahn, who has a lot of experience and familiarity with ZFS on > Solaris, seemed to know exactly the behaviour I described. Others on > FreeBSD have reported the same behaviour as well, just not in that > thread circa 2011. Similar symptoms can have different causes. =20 > Regarding "sched traces", please expand and include instructions. I'm referring to the stuff that is fed into: /usr/src/tools/sched/schedgraph.py It can be created with ktrace and dtrace and I believe the "documentation" is buried in the various "the scheduler sucks" threads. > > It's also unclear to me why the dedup and compression issues should > > be related. There are lots of dedup performance issues reported for > > Solaris as well and I doubt that they can be fixed for FreeBSD without > > significantly deviating from the ZFS upstream. >=20 > What part of Bob's statement did you not understand? Here, let me > repeat it verbatim: >=20 > "Solaris solved the problem by putting the zfs writer threads into a=20 > special scheduling class so that they are usually lower priority than=20 > normal processing. Before this change, a desktop system would become=20 > almost unusable (intermittent loss of keyboard/mouse) while writing=20 > lots of data with compression enabled. Some NFS servers encountered=20 > severe enough issues that NFS clients reported NFS timeouts." My impression from reading zfs-discuss@ is that dedup performance and some interactivity issues actually still exist in Illumos and that they are completely unrelated to zfs writer threads. As I can't use dedup on my systems I don't really pay attention to them, though. > > I'm not saying a PR would be useless, but in my experience PRs > > with insufficient information just stay open and if the problem > > isn't important enough for you to provide additional information > > filing a PR is unlikely to have a great impact: > > http://www.freebsd.org/cgi/query-pr-summary.cgi?category=3D&text=3Dzfs >=20 > Then someone in the know needs to explain exactly *what* data would help > and (more importantly) *how* to go about providing it (i.e. what to > enable in the kernel, what commands to issue, etc.). Eidan has > repeatedly insisted that PRs are a Good Thing(tm) because they allow for > an official way to track issues vs. mailing list threads that start and > turn into tumbleweeds (just like the one I've referenced). And how many of those PRs are actually solved? This is a rhetoric question and I don't expect you to look it up. I'm not saying that PRs are a bad thing, but filing PRs is the easy part and in my experience issues that don't spark developer interest on the mailing lists are usually also ignored when filed as PR, especially when they don't contain 100% of the information that may be relevant. Even if you provide "proof" that the priorities are indeed the cause of the problem there's a fair chance that the PR gets ignored anyway. I currently have four somewhat ZFS-related PRs open, the first was filed in 2007. I still don't think that the solution is that nobody works on ZFS improvements until my PRs are solved. I'm looking forward to using LZ4 which promises better compression than lzjb with less interactivity impact than gzip. It might even work for your /dev/random test as it's supposed to better deal with poorly compressible data. > Without those necessary instructions, in effect what you're asking me to > do is "prove" that the problem exists, which I have already done so. > You just don't like the data I've provided. I don't expect you to "prove" that the problem exists. My impression is that the interactivity issues with gzip have been well known for years and exist since the ZFS import. I also don't dislike your data, all I'm saying is that there could be other explanations. > Bottom line: people enable compression on an fs, issue large amounts of > write I/O to that fs (say hundreds of megabytes, or gigabytes), and > start to see the entire system intermittently stalling hard (for > multiple seconds at a time). This affects everything from switching VTs > on physical console to packets going across SSH. The stalls vary in > duration depending on what compression type is used (lzjb vs. gzip-1 -- > I cannot even imagine what gzip-9 would be like). I described it as > verbosely as I could, including going back and "re-testing" because > people felt the "ZFSv28 import might have addressed it" (it did not): >=20 > http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012752.html I'm aware that the interactivity issues with gzip still exist with ZFSv"5000" and don't deny that similar issues might exist with lzjb (even though it works for me). I don't think anyone is denying that gzip compression currently works poorly for some work loads. Fixing it apparently just isn't considered a priority and thus the issue still exists. Fabian --Sig_//+Dl4ssRW1LsCxzojoB9S8J Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEXkxMACgkQBYqIVf93VJ1w1ACcCzjZQJqDHz7T9sdhajDBBz7Y ZPQAnizFbH2RpjnFvb+yJILwOiS8UzvN =icGT -----END PGP SIGNATURE----- --Sig_//+Dl4ssRW1LsCxzojoB9S8J-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 10 14:42:05 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 23354EF7; Sun, 10 Feb 2013 14:42:05 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by mx1.freebsd.org (Postfix) with ESMTP id CE48B117; Sun, 10 Feb 2013 14:42:04 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id dn14so5405056obc.32 for ; Sun, 10 Feb 2013 06:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; bh=EoeVcwbPnyFoKlZJur6SQdT7UYmGyfyHjDTbt2LIEOY=; b=PV6C1TVZ7J/89r8VyAezuntOsfFz+hVHVV5Ado87XoRR4Q1hZRBtoAXS46wdShWmIF YK0qt7M7JczTPCSJQyyjRdzE+kSt7tRZHXEKAFip5pgx+UqcHpn1HTbn4suOhVfn76rV Fk6WezL7Fna2sXkd8BpbNZLB+AFsKOFrI0/fgoW0r//oOnf7bIBfjh9FJcUAevCwaPjG vmCYkH9serV9E6YqfyLPz2YR4MGxR3K0zWTfGhFrHQyU52gq7cS3tzI3YBcDcJWbJ7o9 2nbA7+hSgE40wUWFn0rD4h0AURlfAWo031ny/xxEl5PP9cmceGluoT82Nc3XitgtV0Oe eI+A== MIME-Version: 1.0 X-Received: by 10.60.171.170 with SMTP id av10mr8833796oec.78.1360507324020; Sun, 10 Feb 2013 06:42:04 -0800 (PST) Sender: pali.gabor@gmail.com Received: by 10.182.87.195 with HTTP; Sun, 10 Feb 2013 06:42:03 -0800 (PST) Date: Sun, 10 Feb 2013 15:42:03 +0100 X-Google-Sender-Auth: grE6A8Aps3Urt7Qvc1AOKYve_Tk Message-ID: Subject: Reminder: FreeBSD Quarterly Status Reports, July--December, 2012 From: Gabor Pali To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, 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: Sun, 10 Feb 2013 14:42:05 -0000 Hello there, Let me call your attention to the approaching deadline of the next set(s) of FreeBSD Quarterly Status Reports. Please consider submitting a few lines on your FreeBSD-related project, we are counting on all of you! :-) On Sun, Jan 13, 2013 at 10:57 PM, Gabor Pali wrote: > Please note that the deadline for submissions covering the period > between July and December 2012 is February 17th, 2013. You can find more details on submission at the Project's web site [1] but you are free to ask me directly (in private) if you need help with this. [1] http://www.freebsd.org/news/status/ From owner-freebsd-stable@FreeBSD.ORG Sun Feb 10 17:18:14 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7DD0C88C for ; Sun, 10 Feb 2013 17:18:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 09DD88D3 for ; Sun, 10 Feb 2013 17:18:13 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id ez12so2421404wid.11 for ; Sun, 10 Feb 2013 09:18:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4JdDIeIfx7axDkjgVS01C8CP/kcr+wx1++bPcLAPH0Q=; b=eEyCcikgeTv3r70zD/XKzfjLn03i5v33yph5nFmurDUIF1p/3jDjI7BcdrJeMxXJoW cs5YZQi2v5v0mvqyxNAztExI7BdVSgqDyMDVIkq2gsgqo+AfClyz5uJ838fxJIjjn334 YIcFNACZGr1JJK0QvIEDRvQN4SpXGzOwy+Kxw8Ty9nQHubQdS29pm3ERpo9ys5VuqD3F HQxGFuRI/HQDDitDlk97d8BgstXEhcghUyD+mArn0bMWPKiQrwUdDfud8Nj2G/yNUjiB 89z98wmPqhp647vvm6OJmGL2A437fcLinbRaM8WMxQsI/aLpcoEkmWqAh9ynqFEHMr91 jYCg== MIME-Version: 1.0 X-Received: by 10.180.99.227 with SMTP id et3mr11836155wib.6.1360516686752; Sun, 10 Feb 2013 09:18:06 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Sun, 10 Feb 2013 09:18:06 -0800 (PST) In-Reply-To: References: Date: Sun, 10 Feb 2013 09:18:06 -0800 X-Google-Sender-Auth: TZmTiLEzQ9d7zCz-q7CmxrBfBNE Message-ID: Subject: Re: ath patch from the head From: Adrian Chadd To: Michael BlackHeart Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 17:18:14 -0000 Hi, I have a HAL in progress for the AR9380 and later chips. I've implemented the basic driver and framework changes needed to support the AR9380 HAL (specifically the newer TX/RX DMA handling). However I'm still going through the process at ${WORK} (1) to get this HAL open sourced so I can push it into FreeBSD. I'll let everyone know when this is done. And for the record - I recently checked whether -HEAD (with the yet-to-be-released AR9380 HAL) still worked with the AR9380 and AR9485. The answer is "yes". :-) Thanks, Adrian (1) I work for Qualcomm Atheros. On 9 February 2013 13:05, Michael BlackHeart wrote: > Hello there, > May be I've missed something or just can't find in the web, but > As I see in HEAD there're some movement around ath driver and it seems > to me that there's driver for AR93xx, especially AR938x, chip 0030. > Is there any patches to stable to check this driver out, 'cause I just > can't compile in this driver from the HEAD on 9.stable? > _______________________________________________ > 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 Feb 10 18:16:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 85A31BDD for ; Sun, 10 Feb 2013 18:16:23 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by mx1.freebsd.org (Postfix) with ESMTP id 325F1B10 for ; Sun, 10 Feb 2013 18:16:22 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id d42so2009865qca.29 for ; Sun, 10 Feb 2013 10:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=4VfiioDe5gj+3ZvfnS9ntMV/2BbF6y1p+vCiS+2nKHM=; b=UStO+c1kxTYvDfaqpRUoGWb07GUOgxH2MwzjWLRjpfZyFV6vNIQZRsf0RgZL4Qq46s ucX7GFAzj2Yu1DxT1310n6xCVocwRo+6oja/lUTkpE8EBKRurGrLOv0+co977Y20w2H1 0bDCAbdAdWqdPXMPIqgKSb5cPcdY9+j5mDK5u8o7TCvIIzBChu2CCyg1/b3ytmAX/tCl 0+rAFOPQnXA9Xcyl7guV+bWQc90Vj9yzkQA/S8Pl/gbOnMFpP3vvzo4Hkw43832uBR3q mz87YjJhQCZpu78Dk2QFwg1tmDNRSI89tWrFp+lJht2GE8UMg09cJqasxffrw3rFWUow q9AA== MIME-Version: 1.0 X-Received: by 10.49.14.202 with SMTP id r10mr5162770qec.10.1360520176611; Sun, 10 Feb 2013 10:16:16 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Sun, 10 Feb 2013 10:16:16 -0800 (PST) Date: Sun, 10 Feb 2013 19:16:16 +0100 X-Google-Sender-Auth: 5W3XCxKSABYXg_qVJZXkq-fZY-k Message-ID: Subject: 9.1-RELEASE AMD64 crash under VBox 4.2.6 when IO APIC is disabled From: CeDeROM 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: Sun, 10 Feb 2013 18:16:23 -0000 Hey :-) I have just noticed that booting installation media for FreeBSD 9.1-RELEASE AMD64 from ISO bootonly under VirtualBox 4.2.6 results in a kernel panic both when ACPI is enabled and disabled in the boot dialog screen (seems different cause of crash), when IO APIC is disabled in VBox (which is a default). I thought AMD64 is not related to APIC..? Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 00:31:14 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B9685A73; Mon, 11 Feb 2013 00:31:14 +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 5012EA90; Mon, 11 Feb 2013 00:31:13 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAF47GFGDaFvO/2dsb2JhbABDhk66XHOCHwEBAQMBAQEBIAQnIAEKBRYOCgICDRkCKQEJJgYIBwQBCBQEh2sGDK02kV2BI4wTG4MpgRMDiGaLC4IzgR2PNoMkgVE1 X-IronPort-AV: E=Sophos;i="4.84,639,1355115600"; d="scan'208";a="13343758" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 10 Feb 2013 19:31:06 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 8699CB4171; Sun, 10 Feb 2013 19:31:06 -0500 (EST) Date: Sun, 10 Feb 2013 19:31:06 -0500 (EST) From: Rick Macklem To: Marc Fournier Message-ID: <1946688889.2870936.1360542666536.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <461A7DB1-4693-4AA5-B43C-5F15FE0C4918@hub.org> Subject: Re: 9-STABLE -> NFS -> NetAPP: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 00:31:14 -0000 Marc Fournier wrote: > Hi John =E2=80=A6 >=20 > Does this help? >=20 > root@io:~ # ps auxl | grep du > root 1054 0.0 0.1 16176 6600 ?? D 3:15AM 0:05.38 du -skx /vm/2799 0 > 81426 0 20 0 newnfs > root 12353 0.0 0.1 16176 5104 ?? D Sat03AM 0:05.41 du -skx /vm/2799 0 > 91597 0 20 0 newnfs > root 64529 0.0 0.1 16176 5164 ?? D Fri03AM 0:05.40 du -skx /vm/2799 0 > 43227 0 20 0 newnfs > root 12855 0.0 0.0 16308 1988 0 S+ 5:26AM 0:00.00 grep du 0 12847 0 20 > 0 piperd It is probably too late, but all the lines (without the | grep du) would be more useful. I also include the "H" flag, so it lists threads as well as processes. The above just says the "du" command is waiting for a vnode lock= . The interesting process/thread is the one that is holding a vnode lock while waiting for something else. Are you still getting the: nfs_getpages: error 13 vm_fault: pager read error, pid 11355 (https) messages logged? With John's recent patch, the error# would no longer be 13 if it was caused by the "intr" flag resulting in a Read RPC terminating with EINTR. If you are still getting the above with "error 13", it suggests that the server is replying EACCES for the Read RPC. I suggested before that you check to make sure that the executable had read access for everyone one the file server. Since I didn't hear back, I'll assume this is the case. rick ps: If it is still up and hasn't been rebooted, you could: sysctl debug.kdb.break_to_debugger=3D1 - then type at the console and do the following from the debugger http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ke= rneldebug-deadlocks.html How well this work depends on what options your kernel was built with. > root@io:~ # grep vm /etc/fstab > 192.168.1.254:/vol/basic /vm nfs rw,nolockd,intr 0 0 >=20 > Haven't rebooted yet =E2=80=A6 if there is anything I can do / try before= =E2=80=A6 ? >=20 > The kernel is from Jan 21st =E2=80=A6 >=20 >=20 > On 2013-01-19, at 4:57 AM, John Baldwin wrote: >=20 > > On Tuesday, December 18, 2012 11:58:36 PM Hub- Marketing wrote: > >> I'm running a few servers sitting on top of a NetAPP file server =E2= =80=A6 > >> everything runs great, but periodically I'm getting: > >> > >> nfs_getpages: error 13 > >> vm_fault: pager read error, pid 11355 (https) > > > > Are you using interruptible mounts ("intr" mount option)? > > > > Also, can you get ps output that includes the 'l' flag to show what > > the processes are stuck on? > > > > -- > > John Baldwin >=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" From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 00:56:07 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EA4B811E; Mon, 11 Feb 2013 00:56:07 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 498CFB71; Mon, 11 Feb 2013 00:56:07 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.189]) by hub.org (Postfix) with ESMTP id 3494A458D4C; Sun, 10 Feb 2013 20:56:05 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.189]) (amavisd-maia, port 10024) with ESMTP id 91475-01; Mon, 11 Feb 2013 00:56:04 +0000 (UTC) Received: from [192.168.0.52] (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id 7F98F458D4B; Sun, 10 Feb 2013 20:56:02 -0400 (AST) Content-Type: multipart/mixed; boundary="Apple-Mail=_4E15226B-B282-4E39-9A08-2093243749EB" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 9-STABLE -> NFS -> NetAPP: From: Marc Fournier In-Reply-To: <1946688889.2870936.1360542666536.JavaMail.root@erie.cs.uoguelph.ca> Date: Sun, 10 Feb 2013 16:56:00 -0800 Message-Id: <0EB27C56-93A1-4FAE-9FB5-CAD960098609@hub.org> References: <1946688889.2870936.1360542666536.JavaMail.root@erie.cs.uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1499) X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 00:56:08 -0000 --Apple-Mail=_4E15226B-B282-4E39-9A08-2093243749EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 2013-02-10, at 4:31 PM, Rick Macklem wrote: > Marc Fournier wrote: >> Hi John =85 >>=20 >> Does this help? >>=20 >> root@io:~ # ps auxl | grep du >> root 1054 0.0 0.1 16176 6600 ?? D 3:15AM 0:05.38 du -skx /vm/2799 0 >> 81426 0 20 0 newnfs >> root 12353 0.0 0.1 16176 5104 ?? D Sat03AM 0:05.41 du -skx /vm/2799 0 >> 91597 0 20 0 newnfs >> root 64529 0.0 0.1 16176 5164 ?? D Fri03AM 0:05.40 du -skx /vm/2799 0 >> 43227 0 20 0 newnfs >> root 12855 0.0 0.0 16308 1988 0 S+ 5:26AM 0:00.00 grep du 0 12847 0 = 20 >> 0 piperd > It is probably too late, but all the lines (without the | grep du) = would be > more useful. I also include the "H" flag, so it lists threads as well = as > processes. The above just says the "du" command is waiting for a vnode = lock. > The interesting process/thread is the one that is holding a vnode lock > while waiting for something else. As requested, 'ps auxlH' attached =85 --Apple-Mail=_4E15226B-B282-4E39-9A08-2093243749EB Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > > Are you still getting the: > nfs_getpages: error 13 > vm_fault: pager read error, pid 11355 (https) Fairly quiet: --Apple-Mail=_4E15226B-B282-4E39-9A08-2093243749EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 And that is it since last reboot ~20 days ago =85=20 >=20 > messages logged? >=20 > With John's recent patch, the error# would no longer be 13 if it was > caused by the "intr" flag resulting in a Read RPC terminating with = EINTR. > If you are still getting the above with "error 13", it suggests that > the server is replying EACCES for the Read RPC. > I suggested before that you check to make sure that the executable had > read access for everyone one the file server. Since I didn't hear = back, > I'll assume this is the case. Don't understand this question =85 I have 34 VPSs running off of this = server right now =85 that 'du process' runs against each of those VPSs = every night, and this problem started happening on Friday night's run =85 = ~18 days into uptime =85 so the same process has run repeatedly, with no = issues, 18 times before it hung on Friday =85 also, the hang, once = 'triggered', only seems to recur against the same directory =85 the same = directory doesn't necessarily trigger it, but once it starts, it appears = to do it for the same directory =85 I'm not sure if I've ever seem it = happening to two different directories at the same time =85 Also, please note that the du command is run from the physical server, = as root =85 > rick > ps: If it is still up and hasn't been rebooted, you could: > sysctl debug.kdb.break_to_debugger=3D1 > - then type at the console and do the following > from the debugger > = http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerne= ldebug-deadlocks.html > How well this work depends on what options your kernel was built = with. My remote console on that one doesn't work very well =85 I can view, but = I can't type =85 --Apple-Mail=_4E15226B-B282-4E39-9A08-2093243749EB-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 01:43:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D9CC5840; Mon, 11 Feb 2013 01:43:22 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 7A538E2A; Mon, 11 Feb 2013 01:43:22 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.188]) by hub.org (Postfix) with ESMTP id C581012B9501; Sun, 10 Feb 2013 21:43:21 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.188]) (amavisd-maia, port 10024) with ESMTP id 28996-09; Mon, 11 Feb 2013 01:43:21 +0000 (UTC) Received: from [192.168.0.52] (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id 4A26812B94FD; Sun, 10 Feb 2013 21:43:20 -0400 (AST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 9-STABLE -> NFS -> NetAPP: From: Marc Fournier In-Reply-To: <0EB27C56-93A1-4FAE-9FB5-CAD960098609@hub.org> Date: Sun, 10 Feb 2013 17:43:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <61DAA500-EB20-4861-AA7F-402FF1047B81@hub.org> References: <1946688889.2870936.1360542666536.JavaMail.root@erie.cs.uoguelph.ca> <0EB27C56-93A1-4FAE-9FB5-CAD960098609@hub.org> To: Rick Macklem X-Mailer: Apple Mail (2.1499) Cc: freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 01:43:22 -0000 Just reset server, so any further details will have to be 'next time' =85 = but, just did a csup and am rebuilding =85 the following three files = were modified since last build: grep nfs /tmp/output Edit src/sys/fs/nfs/nfs_commonsubs.c Edit src/sys/fs/nfsclient/nfs_clrpcops.c Edit src/sys/fs/nfsserver/nfs_nfsdserv.c On 2013-02-10, at 4:56 PM, Marc Fournier wrote: >=20 > On 2013-02-10, at 4:31 PM, Rick Macklem wrote: >=20 >> Marc Fournier wrote: >>> Hi John =85 >>>=20 >>> Does this help? >>>=20 >>> root@io:~ # ps auxl | grep du >>> root 1054 0.0 0.1 16176 6600 ?? D 3:15AM 0:05.38 du -skx /vm/2799 0 >>> 81426 0 20 0 newnfs >>> root 12353 0.0 0.1 16176 5104 ?? D Sat03AM 0:05.41 du -skx /vm/2799 = 0 >>> 91597 0 20 0 newnfs >>> root 64529 0.0 0.1 16176 5164 ?? D Fri03AM 0:05.40 du -skx /vm/2799 = 0 >>> 43227 0 20 0 newnfs >>> root 12855 0.0 0.0 16308 1988 0 S+ 5:26AM 0:00.00 grep du 0 12847 0 = 20 >>> 0 piperd >> It is probably too late, but all the lines (without the | grep du) = would be >> more useful. I also include the "H" flag, so it lists threads as well = as >> processes. The above just says the "du" command is waiting for a = vnode lock. >> The interesting process/thread is the one that is holding a vnode = lock >> while waiting for something else. >=20 > As requested, 'ps auxlH' attached =85 >=20 >=20 > >=20 >>=20 >> Are you still getting the: >> nfs_getpages: error 13 >> vm_fault: pager read error, pid 11355 (https) >=20 > Fairly quiet: >=20 > >=20 > And that is it since last reboot ~20 days ago =85=20 >=20 >>=20 >> messages logged? >>=20 >> With John's recent patch, the error# would no longer be 13 if it was >> caused by the "intr" flag resulting in a Read RPC terminating with = EINTR. >> If you are still getting the above with "error 13", it suggests that >> the server is replying EACCES for the Read RPC. >> I suggested before that you check to make sure that the executable = had >> read access for everyone one the file server. Since I didn't hear = back, >> I'll assume this is the case. >=20 > Don't understand this question =85 I have 34 VPSs running off of this = server right now =85 that 'du process' runs against each of those VPSs = every night, and this problem started happening on Friday night's run =85 = ~18 days into uptime =85 so the same process has run repeatedly, with no = issues, 18 times before it hung on Friday =85 also, the hang, once = 'triggered', only seems to recur against the same directory =85 the same = directory doesn't necessarily trigger it, but once it starts, it appears = to do it for the same directory =85 I'm not sure if I've ever seem it = happening to two different directories at the same time =85 >=20 > Also, please note that the du command is run from the physical server, = as root =85 >=20 >> rick >> ps: If it is still up and hasn't been rebooted, you could: >> sysctl debug.kdb.break_to_debugger=3D1 >> - then type at the console and do the following >> from the debugger >> = http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerne= ldebug-deadlocks.html >> How well this work depends on what options your kernel was built = with. >=20 > My remote console on that one doesn't work very well =85 I can view, = but I can't type =85 >=20 >=20 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 10:37:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 55FEA652 for ; Mon, 11 Feb 2013 10:37:42 +0000 (UTC) (envelope-from prvs=07549c782d=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id EFDFD19CA for ; Mon, 11 Feb 2013 10:37:41 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U4qlW-00020e-7S for freebsd-stable@freebsd.org; Mon, 11 Feb 2013 11:37:38 +0100 Date: Mon, 11 Feb 2013 11:37:38 +0100 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Subject: Re: patch which implements ZFS LZ4 compression Message-ID: <20130211103737.GS38901@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org References: <511581C9.5040608@delphij.net> <20130208230830.GA45081@icarus.home.lan> <20130209151918.221176cd@fabiankeil.de> <20130209204436.GA67890@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130209204436.GA67890@icarus.home.lan> X-Face: "TT~P'b_)-jKU_0^a=usXryz`YTz)z.[FZrI,A~PREI2U}frrZ`>_J&; ^t|^.dR/mqtC,Vb.Y>~u8(|aL)vAv(k">zY"]*m*y|b8S7:WK[/qP5i>HO#Ek; C[X:b|FP0*Ly_4Ni User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Oliver Brandmueller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 10:37:42 -0000 Hi, On Sat, Feb 09, 2013 at 12:44:36PM -0800, Jeremy Chadwick wrote: > Bottom line: people enable compression on an fs, issue large amounts of > write I/O to that fs (say hundreds of megabytes, or gigabytes), and > start to see the entire system intermittently stalling hard (for > multiple seconds at a time). This affects everything from switching VTs > on physical console to packets going across SSH. The stalls vary in > duration depending on what compression type is used (lzjb vs. gzip-1 -- > I cannot even imagine what gzip-9 would be like). I described it as > verbosely as I could, including going back and "re-testing" because > people felt the "ZFSv28 import might have addressed it" (it did not): > > http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012752.html > > The exact same behaviour happens if dedup is used. There is no relation > between compression (the feature) and dedup (the feature), obviously, > but the symptom I've described matches Bob's explanation perfectly. > > If you want to provide the aforementioned instructions, I'll happily > follow them. Did you try using 4BSD instead of ULE at some point? I had similar problems and that completely fixed it for me. Which would mean, that there's some interactio between scheduler and ZFS code. - Oliver -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 11:33:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C9DF7A5E for ; Mon, 11 Feb 2013 11:33:09 +0000 (UTC) (envelope-from p.christias@noc.ntua.gr) Received: from ulysses.noc.ntua.gr (ulysses.noc.ntua.gr [147.102.222.230]) by mx1.freebsd.org (Postfix) with ESMTP id 4B4201F2B for ; Mon, 11 Feb 2013 11:33:08 +0000 (UTC) Received: from ajax.noc.ntua.gr (ajax6.noc.ntua.gr [IPv6:2001:648:2000:dc::1]) by ulysses.noc.ntua.gr (8.14.5/8.14.5) with ESMTP id r1BBNrg5059445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 11 Feb 2013 13:23:53 +0200 (EET) (envelope-from p.christias@noc.ntua.gr) Received: from ajax.noc.ntua.gr (localhost [127.0.0.1]) by ajax.noc.ntua.gr (8.14.5/8.14.4) with ESMTP id r1BBNr2S085589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 11 Feb 2013 13:23:53 +0200 (EET) (envelope-from p.christias@noc.ntua.gr) Received: (from christia@localhost) by ajax.noc.ntua.gr (8.14.5/8.14.4/Submit) id r1BBNr4r085588 for freebsd-stable@freebsd.org; Mon, 11 Feb 2013 13:23:53 +0200 (EET) (envelope-from p.christias@noc.ntua.gr) X-Authentication-Warning: ajax.noc.ntua.gr: christia set sender to p.christias@noc.ntua.gr using -f Date: Mon, 11 Feb 2013 13:23:53 +0200 From: Panagiotis Christias To: freebsd-stable@freebsd.org Subject: Installing FreeBSD 9.1 amd64 on IBM x3550 M3 Message-ID: <20130211112352.GA84742@noc.ntua.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.5 at ulysses.noc.ntua.gr X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (ulysses.noc.ntua.gr [IPv6:2001:648:2000:de::230]); Mon, 11 Feb 2013 13:23:53 +0200 (EET) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Feb 2013 11:33:09 -0000 Hello, I'm trying to install FreeBSD 9.1 amd64 on an IBM x3550 M3 server. Installation went smoothly, RAID controller and network cards were successfully recognised. But, after the installation, the server fails to boot from disk. There were some posts, about two years ago, in this list implying that the problem lies in UEFI but I couldn't find any clear solution. Any suggestions would be greatly appreciated. Thanks, Panagiotis -- Panagiotis J. Christias Network Management Center P.Christias@noc.ntua.gr National Technical Univ. of Athens, GREECE From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 12:05:06 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 65856888 for ; Mon, 11 Feb 2013 12:05:06 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from eris.bzerk.org (unknown [IPv6:2001:980:18dd:1:192:168:179:45]) by mx1.freebsd.org (Postfix) with ESMTP id D6C42264 for ; Mon, 11 Feb 2013 12:05:05 +0000 (UTC) Received: from eris.bzerk.org (BOFH@localhost [127.0.0.1]) by eris.bzerk.org (8.14.5/8.14.5) with ESMTP id r1BC51rK023709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Feb 2013 12:05:01 GMT (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by eris.bzerk.org (8.14.5/8.14.5/Submit) id r1BC51Pd023708 for freebsd-stable@freebsd.org; Mon, 11 Feb 2013 12:05:01 GMT (envelope-from mail25@bzerk.org) X-Authentication-Warning: eris.bzerk.org: bulk set sender to mail25@bzerk.org using -f Date: Mon, 11 Feb 2013 12:05:01 +0000 From: Ruben de Groot To: freebsd-stable@freebsd.org Subject: MFC openssh fix versionaddendum? Message-ID: <20130211120501.GA23676@eris.bzerk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-11.0 required=5.0 tests=ALL_TRUSTED,AUTHD_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eris.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (eris.bzerk.org [127.0.0.1]); Mon, 11 Feb 2013 12:05:04 +0000 (UTC) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Feb 2013 12:05:06 -0000 http://www.freebsd.org/cgi/query-pr.cgi?pr=163843 The fix was committed to -current, but in 9.1 it's still not working. cheersRuben From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 12:11:51 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3AC95C1B for ; Mon, 11 Feb 2013 12:11:51 +0000 (UTC) (envelope-from erich@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id 015572D8 for ; Mon, 11 Feb 2013 12:11:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=w38/0uSjIcVbmrqwX3f2XbaS7m8nRpN70RSJzDTjnJ8=; b=0LmsKREes5KPvtd/iGLFA6tl8Qcek3CA09JWrHwin8jwJDHaV/ea8hLGH658JdYcZBzEpJgyz5XKEL/Gi3/bnTYWW9XBEGV8oRi9Isji2zaJ10oe0+ZWnIgJpLW900uR; Received: from [122.129.203.50] (port=23848 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U4sEf-001IEt-Am; Mon, 11 Feb 2013 05:11:50 -0700 Date: Mon, 11 Feb 2013 19:11:45 +0700 From: Erich Dollansky To: Panagiotis Christias Subject: Re: Installing FreeBSD 9.1 amd64 on IBM x3550 M3 Message-ID: <20130211191145.2b96ba8f@X220.ovitrap.com> In-Reply-To: <20130211112352.GA84742@noc.ntua.gr> References: <20130211112352.GA84742@noc.ntua.gr> Organization: ALO Green Technologies X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erich@alogt.com X-Source: X-Source-Args: X-Source-Dir: 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, 11 Feb 2013 12:11:51 -0000 Hi, On Mon, 11 Feb 2013 13:23:53 +0200 Panagiotis Christias wrote: > Hello, > > I'm trying to install FreeBSD 9.1 amd64 on an IBM x3550 M3 server. > Installation went smoothly, RAID controller and network cards were > successfully recognised. > > But, after the installation, the server fails to boot from disk. > There were some posts, about two years ago, in this list implying > that the problem lies in UEFI but I couldn't find any clear > solution. > I do not know if this is the same problem I face on my notebook but it currently does not boot when I use GPT. Can you give a MBR partitioned disk a try? My notebook was earlier booting from a GPT disk. I cannot remember why I used MBR for the new disk. Erich From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 14:29:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C44A8720; Mon, 11 Feb 2013 14:29:05 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by mx1.freebsd.org (Postfix) with ESMTP id 7E996381; Mon, 11 Feb 2013 14:29:05 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id bs12so1188533qab.11 for ; Mon, 11 Feb 2013 06:28:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=WYjZzBfEhUsD3jwPCMFSXojL4JQWOd6JlETHLtMX/DE=; b=ZWCq4nEUd5e4gSslvmfgZuO8khHfsT6iehtivPtZ2p2LppKum1ITmQZu72+ksnnaQU 2SuKaYS/UNUpsk60PUdj8tPF1MhvxacDwMILfHy1Vpklb+fEW2KdA3Yr2JPDU8bySead edk99jLHI7Brg1m1is7+Q29je22wKSWL/ieCo1mpf81A9x/Pyp21smEDehMm6kBU4Ond jHOQ0cOwQ5Otg2BBHyrt7SMgvrE0qivjQCH0YnQZhK5kwdO7fHZCB7dJ070773mngYYD vlhi6XM6kjz9g0kn9vgajCxXfPj8k+0eGX4w3dvp7iVPNFFPezBPeV1okF+H1i4yeRv9 i7Xw== MIME-Version: 1.0 X-Received: by 10.229.69.100 with SMTP id y36mr1259661qci.34.1360591582127; Mon, 11 Feb 2013 06:06:22 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Mon, 11 Feb 2013 06:06:21 -0800 (PST) Date: Mon, 11 Feb 2013 15:06:21 +0100 X-Google-Sender-Auth: vjuLjkoKTzat02u4VOdiSyYKWKo Message-ID: Subject: 9.1 AMD64 multitasking efficiency low From: CeDeROM To: freebsd-stable@freebsd.org, freebsd-emulation@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: Mon, 11 Feb 2013 14:29:05 -0000 Hello :-) I have found 9.1 to be far more less responsive than 9.0 and previous releases on my desktop. I have noted this slow down at 9.1-RC. I have AMD64 4GB RAM i3 CPU and when I simply run Chromium, VBox with Windows XP 64bit (1GB allocated) and VBox with Ubuntu 64bit (1GB allocated) my machine gets unresponsive - it does not even respond to ACPI shutdown, I need to kill it to get working again :-( I did not happen before. I have also noted that VBox 4.2.6 is working far more slower and makes bigger impact on the whole host performance - sometimes I need to wait some seconds to get the machine response back, this happens especially at loading stage :-( Is there any way to get back the efficiency of my FreeBSD? Maybe I need to bump some configuration to make it more efficient? :-) Any hints appreciated :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 15:41:14 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A2ED4242 for ; Mon, 11 Feb 2013 15:41:14 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by mx1.freebsd.org (Postfix) with ESMTP id 671219BE for ; Mon, 11 Feb 2013 15:41:13 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id ni5so6215242obc.12 for ; Mon, 11 Feb 2013 07:41:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluelife.at; s=google; h=mime-version:x-received:sender:x-originating-ip:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=e3sxPJ7TarAraPGkipNqm82dbXGG85xr1XaH3C+yq34=; b=Hr4wHoIucqZRF6+uqZBVWe21CKPvLtEkiN17SLZ70LuHoTq8DHE0jWNkETohWL8wqF xxU7tfSsXpIRBVjRjOQJnzGudOP6WQwlWG22HKsS30GmBKcrA4kmtG/jyTJhIVLyYsWZ igNDhKc4GQ+K7ylCfzYGCxwcvBseoblbwqg8E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:x-originating-ip:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=e3sxPJ7TarAraPGkipNqm82dbXGG85xr1XaH3C+yq34=; b=a7iRda+xlT15SI3HR/LVpPrhqfijOh4AfqIpXJqwEh4hahEXHZnR/cqGTBXkeIc+oE DctgQqv0aasvd/EyIfJO2rGxCATa0mTfr3K3XckZCuY1YxTLxwStZpyAAB2qj3bUbxc9 08olcudjWcKYUb11sgqhhc/A/V0bwk4J8kYcN5oo58zBjhcWJq9lqSlGUIJs57HWYB/0 QAtQYL4uLoC8N8JJw9JxAA8aTsa5n74/77Ev3I2du8RgO0/gmm7Lx6xZn4h0QKtE9UwW 9EhjpUOtoXLoItphcfxvTbgig6BaV05sf1ViQONP7FRsxDgoIhg3J4MbnTz65agI3bxi SV6g== MIME-Version: 1.0 X-Received: by 10.60.7.129 with SMTP id j1mr10793883oea.54.1360597266995; Mon, 11 Feb 2013 07:41:06 -0800 (PST) Sender: decke@bluelife.at Received: by 10.76.22.134 with HTTP; Mon, 11 Feb 2013 07:41:06 -0800 (PST) X-Originating-IP: [80.123.233.199] In-Reply-To: References: Date: Mon, 11 Feb 2013 16:41:06 +0100 X-Google-Sender-Auth: Jo3fl_VkiIJvYPJzHhAJmWxaSYY Message-ID: Subject: Re: 9.1 AMD64 multitasking efficiency low From: =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= To: CeDeROM Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlKLKexa7SfwRq3POBEeK6mOilTOfddDHJhlq5XIhKyBPTUrU635mO3HmFlvXppFRkfTojO Cc: freebsd-emulation@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, 11 Feb 2013 15:41:14 -0000 On Mon, Feb 11, 2013 at 3:06 PM, CeDeROM wrote: > Hello :-) > > I have found 9.1 to be far more less responsive than 9.0 and previous > releases on my desktop. I have noted this slow down at 9.1-RC. I have > AMD64 4GB RAM i3 CPU and when I simply run Chromium, VBox with Windows > XP 64bit (1GB allocated) and VBox with Ubuntu 64bit (1GB allocated) my > machine gets unresponsive - it does not even respond to ACPI shutdown, > I need to kill it to get working again :-( I did not happen before. > > I have also noted that VBox 4.2.6 is working far more slower and makes > bigger impact on the whole host performance - sometimes I need to wait > some seconds to get the machine response back, this happens especially > at loading stage :-( > > Is there any way to get back the efficiency of my FreeBSD? Maybe I > need to bump some configuration to make it more efficient? :-) > > Any hints appreciated :-) > Tomek You can try to switch to emulators/virtualbox-ose-legacy which is VirtualBox 4.1.x just to rule out that this is a vbox regression. Just be sure to power down the VMs first. It would be interesting to watch if the machine starts to swap when that is all running. -- Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 15:48:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B470C5EE; Mon, 11 Feb 2013 15:48:29 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by mx1.freebsd.org (Postfix) with ESMTP id 58ECEA33; Mon, 11 Feb 2013 15:48:29 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id dx4so1228418qab.9 for ; Mon, 11 Feb 2013 07:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cjzHaUf9ELrVVemqL4f9uDHMc37oGbj3ZAVpWfKSjC8=; b=ZISnSDEPMw283I9lvTLq0o02AmGNvyiSHP9/Ygk97VQaCJMTywQnJ+vf54v7oHSvwz VrIJv2HSxivJJAF/mBx1Fg+ksAXnVlOtauBtvGH2VFSJKzn4Sc4F/d7Ev6yj0T0rrJmr 8fCk1/j7dziU7ir8PmA3L23y94dIr78HQCMfO946pOFEVZM3vavnr+A0HEseogaLlLPl WdEyclgsivCeZmrrXRtILLE7cNOgN66sxfrk7Ca7XuL5l+USSUkh+UCA/lKku8lIM5az fjf15VAss6kIuSgid0O8xzXVXu6+zTkXPsD6mdkAyDK212r/ANQ1IpPAiPv3hXZpuk7e JdpA== MIME-Version: 1.0 X-Received: by 10.229.177.14 with SMTP id bg14mr1328424qcb.51.1360597703144; Mon, 11 Feb 2013 07:48:23 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Mon, 11 Feb 2013 07:48:22 -0800 (PST) In-Reply-To: References: Date: Mon, 11 Feb 2013 16:48:22 +0100 X-Google-Sender-Auth: qo3PzQOEmKBMiHilDclv-kpANjY Message-ID: Subject: Re: 9.1 AMD64 multitasking efficiency low From: CeDeROM To: =?UTF-8?Q?Bernhard_Fr=C3=B6hlich?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-emulation@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, 11 Feb 2013 15:48:29 -0000 On Mon, Feb 11, 2013 at 4:41 PM, Bernhard Fr=C3=B6hlich = wrote: > You can try to switch to emulators/virtualbox-ose-legacy which is > VirtualBox 4.1.x > just to rule out that this is a vbox regression. Just be sure to power > down the VMs > first. > It would be interesting to watch if the machine starts to swap when that = is all > running. Hello Bernhard, thank you for your hints, I can try with VBox 4.1, but first I will try to get rid of the Ext2 from my system. On another machine I have switched to UFS2 and the speed increased noticably. I will let you know when I transfer all of those GB of data :-) Yes it looks like the cause of the hangup is the swap rush/deadlock but I could not verify it as the machine was unresponsive. Still both machines use 1GB of RAM per VM so still 2GB should be free. With other applications running and the OS taking 1GB itself (what I have seen on some other posts) this may happen :-( Best regards :-) Tomek --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 15:55: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]) by hub.freebsd.org (Postfix) with ESMTP id 4239E93B; Mon, 11 Feb 2013 15:55:00 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by mx1.freebsd.org (Postfix) with ESMTP id EDDCEA8F; Mon, 11 Feb 2013 15:54:59 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id d42so2288670qca.29 for ; Mon, 11 Feb 2013 07:54:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=JuzwGF1sGf+3EfNiIOVcd18uIBxGx3UZq/+hX5rjaLY=; b=piw62SsFznEeoIZNs7GNCKCFMZyUmPeB5OjaUMMnUOFD94P/z9iV/MuvB5/5UUky9l sslCqtor4ZPy7JvtJ/1jj7JHffpfej964UGWC6IKnKdueJZNhY1nzc3OJe5i1uC11gqj IqW4RKg47lgiK12lfcmOwuvP/CoK5z9sBMfC5ngkLaD53IvEtYvx9fb2p9MV2cTJvaov qkDEqt2AkJjcgZcFdWEZaujSMNnIEBi7nFnf7AnzyFKv0oL3tA9VRLoJFmMF47o/CE/h Gdc8fOxus4SivlNfnq3yTF0QHWag/e5AG+8aj2NfFLSApoyvU6TPwgiwUk44iz/mm3hG d5sg== MIME-Version: 1.0 X-Received: by 10.224.209.193 with SMTP id gh1mr5712495qab.86.1360598099313; Mon, 11 Feb 2013 07:54:59 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Mon, 11 Feb 2013 07:54:59 -0800 (PST) In-Reply-To: References: Date: Mon, 11 Feb 2013 16:54:59 +0100 X-Google-Sender-Auth: N6EfTH4EZlIGUE9RQu3xyep0cx0 Message-ID: Subject: Re: 9.1 AMD64 multitasking efficiency low From: CeDeROM To: freebsd-stable@freebsd.org, freebsd-emulation@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: Mon, 11 Feb 2013 15:55:00 -0000 On Mon, Feb 11, 2013 at 3:06 PM, CeDeROM wrote: > I have found 9.1 to be far more less responsive than 9.0 and previous > releases on my desktop. Right now as I backup my data (~250GB) I also notice deadlocks on data transfers. I also noticed that on another machine (6 cores, 16GB RAM) with 9.1-RELEASE AMD64. Maybe the responsiveness issue is related to disk access/transfers..? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 16:00:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 47A9CBFB for ; Mon, 11 Feb 2013 16:00:39 +0000 (UTC) (envelope-from decke@bluelife.at) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by mx1.freebsd.org (Postfix) with ESMTP id 10A1AAE6 for ; Mon, 11 Feb 2013 16:00:38 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id dn14so6243293obc.18 for ; Mon, 11 Feb 2013 08:00:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluelife.at; s=google; h=mime-version:x-received:sender:x-originating-ip:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=tmCi2XzsjC9C1jHHi7+Qmr8/NWsRu9UcO0EC6r3lrK4=; b=ehMnu0Ow6IJk+DM3cmiYS5IIHNewGiDT1pBz5NXTlcAh4icbjGVPeMF2/DVdjRkv/V ZUPfkB3Z3KlciMY3P9CeBjOrmkl0KmSRAhMEoDf/GN7NhOTSSaD8Ucx0t1ciherR25NT F7k2MKqwh7U615BHSwtu4JDoGG/hXRCOdvK9Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:x-originating-ip:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding:x-gm-message-state; bh=tmCi2XzsjC9C1jHHi7+Qmr8/NWsRu9UcO0EC6r3lrK4=; b=MygJ0hk6K5hZ3/dmFAFyqHlucVZoaMB4E+FUCs1+gQoUvQVkmbkGIra+JXzN2z36XL V+W3lcuuP7AlyB8BWo7SW+NBz7IC3xtxFM/7vnURp2v7W7yTTIdMKhajWRwi+oI8cxzh yYgx63ENRD35ivseL0HX7FVLsCyIc+xDSY7lCGnJTGXEJsMn9z+AVs4nr1yAAGqakZY6 1v6sx/LyjnoJz2c2kpdzhAaT5XJ9d3eZX5MBg55Xd4rcWW9v1rU7peRIvc09RdAHpaIC 3rPDkUhSWTrWHDX/WS8IyczBgOBuwRtrzqtPCR2XQZiefdzTB1fIWZmfa5NtpqJj+Koa 52sQ== MIME-Version: 1.0 X-Received: by 10.60.27.161 with SMTP id u1mr10813292oeg.1.1360598438280; Mon, 11 Feb 2013 08:00:38 -0800 (PST) Sender: decke@bluelife.at Received: by 10.76.22.134 with HTTP; Mon, 11 Feb 2013 08:00:38 -0800 (PST) X-Originating-IP: [80.123.233.199] In-Reply-To: References: Date: Mon, 11 Feb 2013 17:00:38 +0100 X-Google-Sender-Auth: 7BPxuA7d9ZVch7x97aTKwJVRlTg Message-ID: Subject: Re: 9.1 AMD64 multitasking efficiency low From: =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= To: CeDeROM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmC+66x12qsdSbuukSSyUu5VxK7y2YBRHacQOHgjbUhKRmcRun5oYx0+BOI5JZDqCp6AQ2N Cc: freebsd-emulation@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, 11 Feb 2013 16:00:39 -0000 On Mon, Feb 11, 2013 at 4:48 PM, CeDeROM wrote: > On Mon, Feb 11, 2013 at 4:41 PM, Bernhard Fr=F6hlich = wrote: >> You can try to switch to emulators/virtualbox-ose-legacy which is >> VirtualBox 4.1.x >> just to rule out that this is a vbox regression. Just be sure to power >> down the VMs >> first. >> It would be interesting to watch if the machine starts to swap when that= is all >> running. > > Hello Bernhard, thank you for your hints, I can try with VBox 4.1, but > first I will try to get rid of the Ext2 from my system. On another > machine I have switched to UFS2 and the speed increased noticably. I > will let you know when I transfer all of those GB of data :-) > > Yes it looks like the cause of the hangup is the swap rush/deadlock > but I could not verify it as the machine was unresponsive. Still both > machines use 1GB of RAM per VM so still 2GB should be free. With other > applications running and the OS taking 1GB itself (what I have seen on > some other posts) this may happen :-( VBox itself also needs some RAM and the emulated Graphics Card which can easily be 128M per VM. --=20 Bernhard Froehlich http://www.bluelife.at/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 16:08:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BCB97DB; Mon, 11 Feb 2013 16:08:39 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by mx1.freebsd.org (Postfix) with ESMTP id 5578BB5B; Mon, 11 Feb 2013 16:08:39 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id g10so1229240qah.18 for ; Mon, 11 Feb 2013 08:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pnwRNt6UIeEX9FMNG/LwElBb+Dmn4p+5sAiZUccIB4o=; b=Hg8xn2Cr+pwRIKFWBSvNtj8nmGzvwEwyk98DfZMIOIdajr16NtsKE+T3IFeoA4Xt7R 7FDeuz1p7X4miCQMPVhRJJdcS6aom6ThrgH7su68PotZyPlNyOCMX88JH77ZweqmjbeC otUr0DvMhrrwLBQmoEnhOwqCGn72l+CmWAv5EugksHyedD4W3i0b6rpWTTyEfVxersHe bluIJfQySokIx3BrDsflkX0PXlw+Ups731Ir5H//eIBNAtj3e2llaiTqNMd1iyHEctvU 3JGioTkW3xTA383gGSZPRL2vJ64KZDOzMPvzREhbX72+uIDkzax9+wjDzVDrZQVQnj32 no+A== MIME-Version: 1.0 X-Received: by 10.224.209.193 with SMTP id gh1mr5731121qab.86.1360598918583; Mon, 11 Feb 2013 08:08:38 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Mon, 11 Feb 2013 08:08:38 -0800 (PST) In-Reply-To: References: Date: Mon, 11 Feb 2013 17:08:38 +0100 X-Google-Sender-Auth: K4-H1VV8uGUJNgPDl0Cb0eo2jco Message-ID: Subject: Re: 9.1 AMD64 multitasking efficiency low From: CeDeROM To: =?UTF-8?Q?Bernhard_Fr=C3=B6hlich?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-emulation@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, 11 Feb 2013 16:08:39 -0000 On Mon, Feb 11, 2013 at 5:00 PM, Bernhard Fr=C3=B6hlich = wrote: > VBox itself also needs some RAM and the emulated Graphics Card which > can easily be 128M per VM. This is what I get with CP and one VBox running - memory use is not that high but the responsiveness is getting low now: last pid: 20852; load averages: 0.66, 0.64, 0.49 up 0+03:28:10 17:06:38 100 processes: 1 running, 97 sleeping, 2 zombie CPU: 3.2% user, 0.0% nice, 1.7% system, 0.3% interrupt, 94.8% idle Mem: 1072M Active, 312M Inact, 2187M Wired, 91M Cache, 395M Buf, 80M Free Swap: 6071M Total, 284M Used, 5786M Free, 4% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAN= D 20846 cd 20 20 0 1489M 1191M uwait 3 1:20 15.48% Virtua= lBox 2199 cd 1 29 0 195M 51276K select 1 20:26 10.69% Xorg 2279 cd 2 22 0 169M 14556K piperd 1 0:47 0.20% Termin= al 20724 root 1 20 0 18112K 3060K vnread 0 2:42 0.10% cp 2500 cd 7 20 0 1106M 199M sbwait 1 3:18 0.00% chrome 2485 cd 21 20 0 503M 99948K uwait 3 1:51 0.00% chrome --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 17:01:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C758FF65 for ; Mon, 11 Feb 2013 17:01:54 +0000 (UTC) (envelope-from chris#@1command.com) Received: from udns.ultimateDNS.NET (24-113-166-192.wavecable.com [24.113.166.192]) by mx1.freebsd.org (Postfix) with ESMTP id 8DE4BEED for ; Mon, 11 Feb 2013 17:01:53 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id r1BH1gbU032872 for ; Mon, 11 Feb 2013 09:01:48 -0800 (PST) (envelope-from chris#@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id r1BH1bRd032871; Mon, 11 Feb 2013 09:01:37 -0800 (PST) (envelope-from chris#@1command.com) Received: from udns.ultimatedns.net ([24.113.166.192]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 11 Feb 2013 09:01:37 -0800 (PST) Message-ID: Date: Mon, 11 Feb 2013 09:01:37 -0800 (PST) Subject: t_delta 16.0106d62009e53600 too long -- Should I be concerned? From: "Chris H" To: "freebsd-stable" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Feb 2013 17:01:54 -0000 Greetings, I received the following last night: Feb 10 23:31:20 udns kernel: t_delta 16.0106d62009e53600 too long Feb 10 23:31:36 udns kernel: t_delta 15.fefb2d70ffb0bf00 too short While I'm _guessing_ disk, I'm not sure from where it originates. Should I be concerned? Thank you for all your time, and consideration. --Chris From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 18:10:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 532A9D33 for ; Mon, 11 Feb 2013 18:10:49 +0000 (UTC) (envelope-from p.christias@noc.ntua.gr) Received: from achilles.noc.ntua.gr (achilles.noc.ntua.gr [147.102.222.210]) by mx1.freebsd.org (Postfix) with ESMTP id A047F272 for ; Mon, 11 Feb 2013 18:10:48 +0000 (UTC) Received: from [147.102.224.67] (ovpn-67.noc.ntua.gr [147.102.224.67]) (authenticated bits=0) by achilles.noc.ntua.gr (8.14.5/8.14.5) with ESMTP id r1BHwfsA038606 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 11 Feb 2013 19:58:45 +0200 (EET) (envelope-from p.christias@noc.ntua.gr) Message-ID: <51193151.2090204@noc.ntua.gr> Date: Mon, 11 Feb 2013 19:58:41 +0200 From: Panagiotis Christias Organization: NTUA NOC User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Erich Dollansky , freebsd-stable@freebsd.org Subject: Re: Installing FreeBSD 9.1 amd64 on IBM x3550 M3 References: <20130211112352.GA84742@noc.ntua.gr> <20130211191145.2b96ba8f@X220.ovitrap.com> In-Reply-To: <20130211191145.2b96ba8f@X220.ovitrap.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (achilles.noc.ntua.gr [147.102.222.210]); Mon, 11 Feb 2013 19:58:46 +0200 (EET) X-Virus-Scanned: clamav-milter 0.97.5 at achilles.noc.ntua.gr X-Virus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Feb 2013 18:10:49 -0000 On 11/2/2013 14:11, Erich Dollansky wrote: > Hi, > > On Mon, 11 Feb 2013 13:23:53 +0200 > Panagiotis Christias wrote: > >> Hello, >> >> I'm trying to install FreeBSD 9.1 amd64 on an IBM x3550 M3 server. >> Installation went smoothly, RAID controller and network cards were >> successfully recognised. >> >> But, after the installation, the server fails to boot from disk. >> There were some posts, about two years ago, in this list implying >> that the problem lies in UEFI but I couldn't find any clear >> solution. >> > I do not know if this is the same problem I face on my notebook but it > currently does not boot when I use GPT. Can you give a MBR partitioned > disk a try? > > My notebook was earlier booting from a GPT disk. I cannot remember why > I used MBR for the new disk. Hello, I suppose trying an 8.3 installation would be the easiest way to use MBR instead of GPT, right; Thanks, Panagiotis -- Panagiotis J. Christias Network Management Center p.christias@noc.ntua.gr National Technical Univ. of Athens, GREECE From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 19:44:01 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7D93EF99 for ; Mon, 11 Feb 2013 19:44:01 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5EB0D9EB for ; Mon, 11 Feb 2013 19:44:01 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id fa11so3271433pad.23 for ; Mon, 11 Feb 2013 11:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ZiA6ktQMFFwZQXKPS5596934PbegAcyX15BNJaRGUcA=; b=FHldhWpeqvqmdHq3p9dI5UWeGgU5hYzCvPqcD82M8e60vxWroLyUBbpmFu7PQ5wNFR 1dD/O8sbatQQKtaINSZpyGnSDfCal7QhXgu788ZPAQDkkL74bHdIgzRJnhw2BjG7NcEd 77Hw2X2IYe1axkvV/jy0MK5W7DXIZIOxySX11MgVN7Rb+uw18Sq8KDrV0YpaI5LgHmQP bRL/KgFdfVUJ50VXR+VzxHZr1hwjZCMhJrriKIqUblJtOLkZuX7YqG87dTlYpGpd33HI Tu+i+8PWxEDn5Kv5yScnhm+Ctkpaeq40oXS/L/d5fm8EAVG+142n4psdos6mh8xyZIwT mgqw== MIME-Version: 1.0 X-Received: by 10.66.73.164 with SMTP id m4mr44116333pav.12.1360611835245; Mon, 11 Feb 2013 11:43:55 -0800 (PST) Received: by 10.67.2.65 with HTTP; Mon, 11 Feb 2013 11:43:55 -0800 (PST) In-Reply-To: <51193151.2090204@noc.ntua.gr> References: <20130211112352.GA84742@noc.ntua.gr> <20130211191145.2b96ba8f@X220.ovitrap.com> <51193151.2090204@noc.ntua.gr> Date: Mon, 11 Feb 2013 11:43:55 -0800 Message-ID: Subject: Re: Installing FreeBSD 9.1 amd64 on IBM x3550 M3 From: Kevin Oberman To: Panagiotis Christias Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, Erich Dollansky X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Feb 2013 19:44:01 -0000 On Mon, Feb 11, 2013 at 9:58 AM, Panagiotis Christias wrote: > On 11/2/2013 14:11, Erich Dollansky wrote: >> >> Hi, >> >> On Mon, 11 Feb 2013 13:23:53 +0200 >> Panagiotis Christias wrote: >> >>> Hello, >>> >>> I'm trying to install FreeBSD 9.1 amd64 on an IBM x3550 M3 server. >>> Installation went smoothly, RAID controller and network cards were >>> successfully recognised. >>> >>> But, after the installation, the server fails to boot from disk. >>> There were some posts, about two years ago, in this list implying >>> that the problem lies in UEFI but I couldn't find any clear >>> solution. >>> >> I do not know if this is the same problem I face on my notebook but it >> currently does not boot when I use GPT. Can you give a MBR partitioned >> disk a try? >> >> My notebook was earlier booting from a GPT disk. I cannot remember why >> I used MBR for the new disk. > > > Hello, > > I suppose trying an 8.3 installation would be the easiest way to use MBR > instead of GPT, right; That would do it, but 9.1 is perfectly happy doing MBR. It's just not the default. Seems like many BIOSes assume that GPT=uEFI. Clearly this is silly, but... I know Lenovo laptops have this problem and it is VERY annoying. I run FreeBSD on a GPT disk on my ThinkPad, but I have booteasy installed on an MBR disk (which contains W7) and my BIOS is set to boot from that disk.BootEasy then will boot up the GPT disk with FreeBSD. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 20:35:14 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 853DFA5D; Mon, 11 Feb 2013 20:35:14 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wi0-x229.google.com (wi-in-x0229.1e100.net [IPv6:2a00:1450:400c:c05::229]) by mx1.freebsd.org (Postfix) with ESMTP id DE84BC25; Mon, 11 Feb 2013 20:35:13 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id l13so3780970wie.4 for ; Mon, 11 Feb 2013 12:35:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=rzVfj/R0zuhpnvZWh6Ev64O9JPm/65ouZui8ff2btOA=; b=NLIFWnenEL4CuSDve11adaqg49kYd1+7A90RW2TSjoP9G4CgWlFj31DEO5gzZ6fGGA b8hJ5YC5/mXm9rG/0gvaPNQt5zX6e1AHVvQuQzGIqdqm3hs33UpjZotEmH1PNe1N1Cyt 9HgX/X2xBoNNA1lTXTDwkjBlsxIxmaGUItzc9/BHW0lcAVr7q62wrJ7AXQ9mVkB0AFjE QsLXF60GNo6LQ24PyHvDHe8WjCTHugRo8633TyBadx3aJozVnrTy57Sv9yyDILpEhSaM L9E0BrGX5cEu/BGEn0CaBpQRFXMWDKIfaJgU173hREnr34+D4shtF6IndqRPFFsAfoi8 A7uw== X-Received: by 10.180.80.74 with SMTP id p10mr18557703wix.19.1360614912206; Mon, 11 Feb 2013 12:35:12 -0800 (PST) Received: from melon.malikania.fr (177.33.91.91.rev.sfr.net. [91.91.33.177]) by mx.google.com with ESMTPS id cu7sm32929471wib.8.2013.02.11.12.35.10 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 11 Feb 2013 12:35:11 -0800 (PST) From: David Demelier To: Andriy Gapon Subject: Re: Panic at shutdown Date: Mon, 11 Feb 2013 21:33:03 +0100 Message-ID: <2314469.VQx5EpHULg@melon.malikania.fr> User-Agent: KMail/4.9.5 (FreeBSD/9.1-STABLE; KDE/4.9.5; amd64; ; ) In-Reply-To: <51136BED.2040607@FreeBSD.org> References: <51127767.1030007@gmail.com> <511286F4.5020208@gmail.com> <51136BED.2040607@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 20:35:14 -0000 Le jeudi 7 f=E9vrier 2013 10:55:09 Andriy Gapon a =E9crit : > Without so much as a stack trace there is nothing to chew on. > A useable vmcore would be better. >=20 > Did you perhaps use kgdb with a mismatching kernel? --=20 I still have panic, and recompiled kernel, the stack info is not better= but I=20 have a lot of message before : (Always related to ACPI) GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and yo= u are welcome to change it and/or distribute copies of it under certain condi= tions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for deta= ils. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: ACPI Error: Object not a Integer, type Reference (20110527/exresnte-210= ) ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node=20 0xfffffe00017eaaf0), AE_AML_OPERAND_TYPE (20110527/uteval-113) ACPI Error: Needed [Integer/String/Buffer], found [Reference]=20 0xfffffe0001807678 (20110527/exresop-533) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for=20 [OpcodeName unavailable] (20110527/dswexec-498) ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.BTDR] (= Node=20 0xfffffe00017e6ac8), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.BSTA] (= Node=20 0xfffffe00017e6aa0), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_SB_.BAT0._STA] (Node=20 0xfffffe00017eaac8), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method execution failed [\_SB_.BAT0._STA] (Node=20 0xfffffe00017eaac8), AE_AML_OPERAND_TYPE (20110527/uteval-113) ACPI Error: Object not a Integer, type Reference (20110527/exresnte-210= ) ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node=20 0xfffffe00017eaaf0), AE_AML_OPERAND_TYPE (20110527/uteval-113) ACPI Error: Needed [Integer/String/Buffer], found [Reference]=20 0xfffffe0001807678 (20110527/exresop-533) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for=20 [OpcodeName unavailable] (20110527/dswexec-498) ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.BTDR] (= Node=20 0xfffffe00017e6ac8), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.BSTA] (= Node=20 0xfffffe00017e6aa0), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_SB_.BAT0._STA] (Node=20 0xfffffe00017eaac8), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method execution failed [\_SB_.BAT0._STA] (Node=20 0xfffffe00017eaac8), AE_AML_OPERAND_TYPE (20110527/uteval-113) ACPI Error: Object not a Integer, type Reference (20110527/exresnte-210= ) ACPI Error: Method execution failed [\_SB_.BAT0._UID] (Node=20 0xfffffe00017eaaf0), AE_AML_OPERAND_TYPE (20110527/uteval-113) ACPI Error: Needed [Integer/String/Buffer], found [Mutex] 0xfffffe00018= 07678=20 (20110527/exresop-533) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for=20 [OpcodeName unavailable] (20110527/dswexec-498) ACPI Error: Method parse/execution failed [\_GPE.HWWP] (Node=20 0xfffffe00017d2208), AE_AML_OPERAND_TYPE (20110527/psparse-560) Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x368 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff804e433b stack pointer =3D 0x28:0xffffff80dd819730 frame pointer =3D 0x28:0xfffffe0003aa3920 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 1543 (upowerd) trap number =3D 12 panic: page fault cpuid =3D 0 Uptime: 2h11m52s Dumping 632 out of 3054=20 MB:..3%..11%..21%..31%..41%..51%..61%..71%..81%..92% Reading symbols from /boot/kernel/vboxdrv.ko...done. Loaded symbols for /boot/kernel/vboxdrv.ko #0 doadump (textdump=3D) at pcpu.h:229 warning: Source file is more recent than executable. 229 #define IS_BSP() (PCPU_GET(cpuid) =3D=3D 0) (kgdb) bt full #0 doadump (textdump=3D) at pcpu.h:229 No locals. #1 0x0000000000000000 in ?? () No symbol table info available. (kgdb) bt full #0 doadump (textdump=3D) at pcpu.h:229 = =20 No locals. = =20 #1 0x0000000000000000 in ?? () = = =20 No symbol table info available. =20 -- David Demelier From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 21:09:42 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BD68A52B for ; Mon, 11 Feb 2013 21:09:42 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 091A3E2E for ; Mon, 11 Feb 2013 21:09:41 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA13147; Mon, 11 Feb 2013 23:09:39 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U50d8-000GmX-Kk; Mon, 11 Feb 2013 23:09:38 +0200 Message-ID: <51195E10.6080204@FreeBSD.org> Date: Mon, 11 Feb 2013 23:09:36 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: David Demelier Subject: Re: Panic at shutdown References: <51127767.1030007@gmail.com> <511286F4.5020208@gmail.com> <51136BED.2040607@FreeBSD.org> <2314469.VQx5EpHULg@melon.malikania.fr> In-Reply-To: <2314469.VQx5EpHULg@melon.malikania.fr> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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, 11 Feb 2013 21:09:42 -0000 on 11/02/2013 22:33 David Demelier said the following: > Le jeudi 7 février 2013 10:55:09 Andriy Gapon a écrit : >> Without so much as a stack trace there is nothing to chew on. >> A useable vmcore would be better. >> >> Did you perhaps use kgdb with a mismatching kernel? Please don't leave stray signature separators in your emails - that makes reading and replying painful in compliant clients - as you can see. The ACPI messages don't tell _me_ much. If your kernel and modules are built with no debugging support whatsoever or .symbols files are missing, then it is almost pointless to get kernel dumps. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 21:12:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 75E49A01 for ; Mon, 11 Feb 2013 21:12:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 14704E66 for ; Mon, 11 Feb 2013 21:12:10 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4B7B0B9AB; Mon, 11 Feb 2013 16:12:10 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: 9.1-RELEASE AMD64 crash under VBox 4.2.6 when IO APIC is disabled Date: Mon, 11 Feb 2013 16:06:06 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302111606.06731.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 11 Feb 2013 16:12:10 -0500 (EST) Cc: CeDeROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Feb 2013 21:12:12 -0000 On Sunday, February 10, 2013 1:16:16 pm CeDeROM wrote: > Hey :-) I have just noticed that booting installation media for > FreeBSD 9.1-RELEASE AMD64 from ISO bootonly under VirtualBox 4.2.6 > results in a kernel panic both when ACPI is enabled and disabled in > the boot dialog screen (seems different cause of crash), when IO APIC > is disabled in VBox (which is a default). I thought AMD64 is not > related to APIC..? > Best regards :-) > Tomek You will need to add 'device atpic' to your kernel config and build a custom kernel. All real amd64-capable hardware has APICs. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 21:39:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 31DBF167; Mon, 11 Feb 2013 21:39:53 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by mx1.freebsd.org (Postfix) with ESMTP id B47B8F93; Mon, 11 Feb 2013 21:39:52 +0000 (UTC) Received: by mail-qe0-f44.google.com with SMTP id a11so2796906qen.31 for ; Mon, 11 Feb 2013 13:39:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XwZd+6ZJmQn5LOWhWfkpRqucg6i/EhiPjHBtweRik50=; b=koYLgN91PaY+UhC4UlVqdIqLT57u+kazhHhoEEQcH/BvZMXdlaik9aoQoTfW39GUn+ bjfzEaSEk522Qe1jAOHCjnhPQGzL6JuBd4oQ7q5dqkTs0Itgda50TuUoDvtK5VAYpJjs 9HrLOynS6Y2dC2MAWI3SU5KaRaMyYa61XkiCzuXSKz6JqpBnh/loeFREK2cmJXqbkFDU J/u9l2KMAuf65dJuHW3dtax20LtEsbju5FakoxMLNI+Zm1g74u1RcW5thua63bLF+ABl vMGP3mH1swv1Bu9YC3mKpAVOvle/vcsZMri3bARzNgJIUkxi1SeZZKZE9n45ep4y7wRl rfDg== MIME-Version: 1.0 X-Received: by 10.224.58.147 with SMTP id g19mr6156141qah.22.1360618477453; Mon, 11 Feb 2013 13:34:37 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Mon, 11 Feb 2013 13:34:37 -0800 (PST) In-Reply-To: <201302111606.06731.jhb@freebsd.org> References: <201302111606.06731.jhb@freebsd.org> Date: Mon, 11 Feb 2013 22:34:37 +0100 X-Google-Sender-Auth: LPJghNiMI0ZP9MGLfgzK5bJlyTg Message-ID: Subject: Re: 9.1-RELEASE AMD64 crash under VBox 4.2.6 when IO APIC is disabled From: CeDeROM To: John Baldwin 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: Mon, 11 Feb 2013 21:39:53 -0000 On Mon, Feb 11, 2013 at 10:06 PM, John Baldwin wrote: > On Sunday, February 10, 2013 1:16:16 pm CeDeROM wrote: >> Hey :-) I have just noticed that booting installation media for >> FreeBSD 9.1-RELEASE AMD64 from ISO bootonly under VirtualBox 4.2.6 >> results in a kernel panic both when ACPI is enabled and disabled in > > You will need to add 'device atpic' to your kernel config and build a custom > kernel. All real amd64-capable hardware has APICs. Hello John :-) Thank you for your reply, still I need some more information to understand why this happens :-) The simple answer that I have deduced is that APIC is MANDATORY for AMD64 machines and they won't run otherwise? This is why generic AMD64 install fails when no APIC is enabled in the VBox? However I was building custom kernel on my AMD64 recently to test new driver and I found this part of Handbook [1] a bit misleading: device apic # I/O APIC The apic device enables the use of the I/O APIC for interrupt delivery. The apic device can be used in both UP and SMP kernels, but is required for SMP kernels. Add options SMP to include support for multiple processors. Note: The apic device exists only on the i386 architecture, this configuration line should not be used on other architectures. Why then APIC is not required in my AMD64 configuration file, but machine requires it..? Where should I add this configuration option - which kernel my host or the generic install and wouldn't that produce error at build time? I am a bit lost :-) Thank you :-) Tomek [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 22:35:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2AD74FFB; Mon, 11 Feb 2013 22:35:16 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by mx1.freebsd.org (Postfix) with ESMTP id B41AF279; Mon, 11 Feb 2013 22:35:15 +0000 (UTC) Received: by mail-qe0-f42.google.com with SMTP id 2so2827919qeb.1 for ; Mon, 11 Feb 2013 14:35:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LxxYbkquJHfHcACf6wiIHTds3TwK7udXDiPy+dPm9ac=; b=wE/lqtUc4sgDQsnk1/GgTriVc1nvFxN5S78pZRv8zmRTAGswupBYwAzux/i5EWQw73 G2GzTH2DHJHuOSgXIyx3PjrOyvbBIOIy1Phb5MYVqIx/Fr9SbTe6J4pZB1sdXMQCNDqT l3QSXzlhO9opQL6Wt9J2wkqjs26F19sJ+6DSFdeRW+b6OEdWLyTFk6gsxceM+wTXTAAH TyY7dFyyje9YoMsv0/4ImGkWzMDN5Uf64W6UpkCJRMAWeNPxPEy+i+34UvOtioARKNTH oc/rSJTYnJp3XSvs6nhtiU4Gjn7Y35ehTuLo1st60g4X04ZeyjLfDA2Ym4qyqmeA6W4d wOsA== MIME-Version: 1.0 X-Received: by 10.224.186.81 with SMTP id cr17mr6057488qab.99.1360622114862; Mon, 11 Feb 2013 14:35:14 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Mon, 11 Feb 2013 14:35:14 -0800 (PST) In-Reply-To: References: Date: Mon, 11 Feb 2013 23:35:14 +0100 X-Google-Sender-Auth: haSWLvLlgoYi8LHWnJxbX4vMATs Message-ID: Subject: Re: 9.1 AMD64 multitasking efficiency low From: CeDeROM To: =?UTF-8?Q?Bernhard_Fr=C3=B6hlich?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-emulation@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, 11 Feb 2013 22:35:16 -0000 On Mon, Feb 11, 2013 at 5:08 PM, CeDeROM wrote: > On Mon, Feb 11, 2013 at 5:00 PM, Bernhard Fr=C3=B6hlich wrote: >> VBox itself also needs some RAM and the emulated Graphics Card which >> can easily be 128M per VM. > > This is what I get with CP and one VBox running - memory use is not > that high but the responsiveness is getting low now: I am now almost sure that these delays are caused by IO and/or MEMORY operations because I can see dramatical decrease in responsivness when: 1. I have constant IO operations provided by copying ~250GB of data from/to external drive. Copying takes really lots of time and slows down the whole system noticably. 2. When any bigger application starts whole system slows down - i.e. my xorg/xfce4 keeps me waiting some seconds for action, still i can hear fluent mp3 stream behind. After application is loaded it works pretty fine until it starts operating on a data or unloads. When VBox starts the vmachine I get terrible glitches, then when everything is loaded system and vmachine works fine until it needs to load something that again slows down the whole system, then when I want to shut down the machine it gets unresponsive. 3. When the swap starts working things also gets really bad. I can work on VESA xorg driver, I can have no multimedia drivers, but the system performance is really important factor for me and working like this is really unpleasant on a pretty modern machine :-( I dont want to even think to switch to Ubuntu :-P Any hints on how to fix this situation are highly welcome :-) --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Mon Feb 11 23: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]) by hub.freebsd.org (Postfix) with ESMTP id 0F44A96E for ; Mon, 11 Feb 2013 23:53:39 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id E942B7C8 for ; Mon, 11 Feb 2013 23:53: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 1U53Bp-0003k9-DZ for freebsd-stable@freebsd.org; Mon, 11 Feb 2013 15:53:37 -0800 Date: Mon, 11 Feb 2013 15:53:37 -0800 (PST) From: Jakub Lach To: freebsd-stable@freebsd.org Message-ID: <1360626817405-5786129.post@n5.nabble.com> In-Reply-To: References: <201302111606.06731.jhb@freebsd.org> Subject: Re: 9.1-RELEASE AMD64 crash under VBox 4.2.6 when IO APIC is disabled 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: Mon, 11 Feb 2013 23:53:39 -0000 As far as I remember, there is no apic option in amd64 kernel, because it's always included. -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-1-RELEASE-AMD64-crash-under-VBox-4-2-6-when-IO-APIC-is-disabled-tp5785747p5786129.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 01:10:43 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 304D57E2 for ; Tue, 12 Feb 2013 01:10:43 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id DC4C7AAE for ; Tue, 12 Feb 2013 01:10:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=0NP/JfNkW24annfP4eBq5XGbyZjFENhMrScwhTOgTCo=; b=ca6zMiE+K6x4lYfMYmvE0VEbsxKWeRnHVIQeb6yy6McsKEruqB8+bkq1ecBBff+wek+/aCZJhxaMIb4gwBy4aWUPBXtjtl5LKF7U57n1ZbhecMyy0tnFfX67O4O0aNTi; Received: from [122.129.203.50] (port=41338 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U54OP-000Zpq-1Z; Mon, 11 Feb 2013 18:10:41 -0700 Date: Tue, 12 Feb 2013 08:10:37 +0700 From: Erich Dollansky To: Panagiotis Christias Subject: Re: Installing FreeBSD 9.1 amd64 on IBM x3550 M3 Message-ID: <20130212081037.1c9a550a@X220.ovitrap.com> In-Reply-To: <51193151.2090204@noc.ntua.gr> References: <20130211112352.GA84742@noc.ntua.gr> <20130211191145.2b96ba8f@X220.ovitrap.com> <51193151.2090204@noc.ntua.gr> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: 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, 12 Feb 2013 01:10:43 -0000 Hi, On Mon, 11 Feb 2013 19:58:41 +0200 Panagiotis Christias wrote: > On 11/2/2013 14:11, Erich Dollansky wrote: > > Hi, > > > > On Mon, 11 Feb 2013 13:23:53 +0200 > > Panagiotis Christias wrote: > > > >> Hello, > >> > >> I'm trying to install FreeBSD 9.1 amd64 on an IBM x3550 M3 server. > >> Installation went smoothly, RAID controller and network cards were > >> successfully recognised. > >> > >> But, after the installation, the server fails to boot from disk. > >> There were some posts, about two years ago, in this list implying > >> that the problem lies in UEFI but I couldn't find any clear > >> solution. > >> > > I do not know if this is the same problem I face on my notebook but > > it currently does not boot when I use GPT. Can you give a MBR > > partitioned disk a try? > > > > My notebook was earlier booting from a GPT disk. I cannot remember > > why I used MBR for the new disk. > > Hello, > > I suppose trying an 8.3 installation would be the easiest way to use > MBR instead of GPT, right; > I run 10 with MBR. It is only a matter of telling either the installation programm or gpart what to do. Erich From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 02:44:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 70079182; Tue, 12 Feb 2013 02:44:45 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by mx1.freebsd.org (Postfix) with ESMTP id 357EBD87; Tue, 12 Feb 2013 02:44:44 +0000 (UTC) Received: by mail-da0-f42.google.com with SMTP id z17so3019613dal.1 for ; Mon, 11 Feb 2013 18:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:from:reply-to:to:cc:in-reply-to:references :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=MqHqLNiuLKLdr4cU4Zu1Wwj/PT60ettYviID0Iz/2fY=; b=rFUXWbLhPZ7Iwakvcop/NKL5j+1jgOUhfXWn0EPRU+/x4zrBTvhNLhmblksJhC1FQH qcufWcg17plItZv3kx3isGMXju6PVDsVPP5aNhknUJmFd6cFBYdmV+c/0UVEq+U6kJVP RxwZj0Qtii3gOryT11YJaS1KBykJkCE8FIsOzUJoYhs9T95phrL7PRdXhYTeRXziBbWm lp+GKU8MNRq9fYV9Bzf+20uU01WX2TVNsXpMInKKLsRXnmVnIt8QJrzlJMU2XJEcLk4/ JjvY/f81x584neo0zNtP4DvhfrPu+OTss1dnGWRPdjQ54GqjSsD9aY5DStWCtLW9r3ru lQQg== X-Received: by 10.66.52.1 with SMTP id p1mr33477976pao.22.1360637084524; Mon, 11 Feb 2013 18:44:44 -0800 (PST) Received: from [192.168.1.210] (c-71-202-40-63.hsd1.ca.comcast.net. [71.202.40.63]) by mx.google.com with ESMTPS id bi2sm71011779pab.18.2013.02.11.18.44.42 (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 11 Feb 2013 18:44:43 -0800 (PST) Subject: Re: Intel 82574 issue reported on Slashdot From: Sean Bruno To: Jack Vogel In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Mon, 11 Feb 2013 18:44:41 -0800 Message-ID: <1360637081.6605.4.camel@powernoodle> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: FreeBSD stable , "Pieper, Jeffrey E" , FreeBSD Net , "Hearn, James R" , "Vogel, Jack" , "Ronciak, John" , FreeBSD Current X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 02:44:45 -0000 On Fri, 2013-02-08 at 10:16 -0800, Jack Vogel wrote: > For those that may have run across the story on Slashdot about this NIC, > here is our statement: > > Recently there were a few stories published, based on a blog post by an > end-user, suggesting specific network packets may cause the Intel® 82574L > Gigabit Ethernet Controller to become unresponsive until corrected by a > full platform power cycle. > > Intel was made aware of this issue in September 2012 by the blogs author. > Intel worked with the author as well as the original motherboard > manufacturer to investigate and determine root cause. Intel root caused the > issue to the specific vendor’s mother board design where an incorrect > EEPROM image was programmed during manufacturing. We communicated the > findings and recommended corrections to the motherboard manufacturer. > > It is Intel’s belief that this is an implementation issue isolated to a > specific manufacturer, not a design problem with the Intel 82574L Gigabit > Ethernet controller. Intel has not observed this issue with any > implementations which follow Intel’s published design guidelines. Intel > recommends contacting your motherboard manufacturer if you have continued > concerns or questions whether your products are impacted. > Here is the link: > > http://communities.intel.com/community/wired/blog/2013/02/07/intel-82574l-gigabit-ethernet-controller-statement > > Any questions or concerns may be sent to me. > > Cheers, > > Jack Thanks for the info. I'm sure there were some *interesting* debugging sessions during this. Sean From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 07:54:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AC4F95D5 for ; Tue, 12 Feb 2013 07:54:29 +0000 (UTC) (envelope-from alexoz66@gmail.com) Received: from mail-ea0-f170.google.com (mail-ea0-f170.google.com [209.85.215.170]) by mx1.freebsd.org (Postfix) with ESMTP id 3B0E7A9B for ; Tue, 12 Feb 2013 07:54:28 +0000 (UTC) Received: by mail-ea0-f170.google.com with SMTP id a11so18702eaa.1 for ; Mon, 11 Feb 2013 23:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5oD7je/Gbk0Of+3tsSTYYSw+mO96DmwguOmAoFlqwO8=; b=sF7hJLxKp+j40G0PNpBJtejYl0If/dU4ddu40mHpdHKwRDUn3i4aceKwKfyvBHNt0Q D0xjQeRN6k86xzYduaDXMZinNJTHY5U5zEAkxRSUSvsAMYG9agBPz2evHoaKzLfMC9AO +3KFfdbtBFDIKIO9siqVKY2x6E4y3rILi4xSsm8MKBkN+yJMUmoygW5Ng4woY8JfXjxi 4Tnip9AT6DQnnBZU6vfPHSG2oXnvr3/CFPahEtKioPzRRpE5M0BGO3iyFN2nva+wai71 DRlQ7woEgnNR69aO5l8aPHDvj6lEWYcysGxLi4kgz5k//LT1OpG7ylH1YVfNu+P66cwp rh3Q== X-Received: by 10.14.224.137 with SMTP id x9mr59959365eep.11.1360655667271; Mon, 11 Feb 2013 23:54:27 -0800 (PST) Received: from alexoz.noc.duth.gr ([2001:648:2e80:10:be5f:f4ff:fe42:7f4d]) by mx.google.com with ESMTPS id j46sm63032992eeo.3.2013.02.11.23.54.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 23:54:26 -0800 (PST) Message-ID: <5119F531.7030707@gmail.com> Date: Tue, 12 Feb 2013 09:54:25 +0200 From: "John Alex." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: kpneal@pobox.com Subject: Re: Installing FreeBSD 9.1 amd64 on IBM x3550 M3 References: <20130211112352.GA84742@noc.ntua.gr> <20130211191145.2b96ba8f@X220.ovitrap.com> <51193151.2090204@noc.ntua.gr> <20130212005913.GA33927@neutralgood.org> In-Reply-To: <20130212005913.GA33927@neutralgood.org> 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: Tue, 12 Feb 2013 07:54:29 -0000 On 02/12/2013 02:59 AM, kpneal@pobox.com wrote: > On Mon, Feb 11, 2013 at 11:43:55AM -0800, Kevin Oberman wrote: >> On Mon, Feb 11, 2013 at 9:58 AM, Panagiotis Christias >> wrote: >>> >>> I suppose trying an 8.3 installation would be the easiest way to use MBR >>> instead of GPT, right; >> >> That would do it, but 9.1 is perfectly happy doing MBR. It's just not >> the default. >> >> Seems like many BIOSes assume that GPT=uEFI. Clearly this is silly, but... >> >> I know Lenovo laptops have this problem and it is VERY annoying. I run >> FreeBSD on a GPT disk on my ThinkPad, but I have booteasy installed on >> an MBR disk (which contains W7) and my BIOS is set to boot from that >> disk.BootEasy then will boot up the GPT disk with FreeBSD. > > Doesn't GPT start with an MBR covering the entire disk? How feasible would > it be to tweak that MBR so that a boot partition was listed in it? Say, a > partition holding the root filesystem could be listed in both the GPT and > MBR style. Then a disk could be booted with MBR or GPT at the whim of the > firmware. > > I agree that this BIOS=MBR/UEFI=GPT assumption is pure rubbish. I've got > machines with this documented restriction and I'd love a way around it. > It is feasible, it's known as a hybrid MBR. On Linux I've accomplished this using the gdisk utility, I don't know how it can be done on FreeBSD though. I had to use this ugly solution in order to install windows 8 on a GPT disk on a pc without UEFI support. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 07:57:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 80FD9714; Tue, 12 Feb 2013 07:57:36 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id E6B87AD4; Tue, 12 Feb 2013 07:57:35 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id x10so5602518wey.17 for ; Mon, 11 Feb 2013 23:57:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6SP8e+Jgik6Bey8S8RChPmZrYauKNTWzawpeRf/hvBo=; b=sMlRzfQi7Y1gQFO8F1eXi07//LRbf2yqoso7vKBPyGDXXf9ceNtwJriHEbBbhkQLed yVuu5s3PE8OAHTV3SnJ8/sIwoyDdQzpx+B3Z5FMtV9IMqO0oTrCUo/fW5K8G5GYIZrmq uURsvaGLd63Y3P0K2LLAHTkVVV+TGITLALe0nnSexrotf3AlxqV7Ns3zs1p4VOWEZPXG wgEIYukMwn52j/GDbZjHbWTDwSXC8NV1tUcv7gsJ6U/7ZhfB8wHRE+XcSbItJbjwNJyS utRCKfq8Y+HbUYa8Pmw5LIfnMndY8PWhf49/gZ2V4v5Tpga950kCwPhzlDSbue2qwtJ2 74HQ== MIME-Version: 1.0 X-Received: by 10.180.80.74 with SMTP id p10mr1214424wix.19.1360655855190; Mon, 11 Feb 2013 23:57:35 -0800 (PST) Received: by 10.194.119.5 with HTTP; Mon, 11 Feb 2013 23:57:35 -0800 (PST) In-Reply-To: <51195E10.6080204@FreeBSD.org> References: <51127767.1030007@gmail.com> <511286F4.5020208@gmail.com> <51136BED.2040607@FreeBSD.org> <2314469.VQx5EpHULg@melon.malikania.fr> <51195E10.6080204@FreeBSD.org> Date: Tue, 12 Feb 2013 08:57:35 +0100 Message-ID: Subject: Re: Panic at shutdown From: David Demelier To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 07:57:36 -0000 Yes I have added debugging option in my kernel. I have makeoptions DEBUG=-g in my config. Do I need more ? I'm not sure to understand what you meant about stray signatures.. -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 08:01:15 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 97AB2972 for ; Tue, 12 Feb 2013 08:01:15 +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 E4352B39 for ; Tue, 12 Feb 2013 08:01:14 +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 KAA18672; Tue, 12 Feb 2013 10:01:12 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U5Ang-000KGi-BC; Tue, 12 Feb 2013 10:01:12 +0200 Message-ID: <5119F6C6.8010802@FreeBSD.org> Date: Tue, 12 Feb 2013 10:01:10 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: David Demelier Subject: Re: Panic at shutdown References: <51127767.1030007@gmail.com> <511286F4.5020208@gmail.com> <51136BED.2040607@FreeBSD.org> <2314469.VQx5EpHULg@melon.malikania.fr> <51195E10.6080204@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 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: Tue, 12 Feb 2013 08:01:15 -0000 on 12/02/2013 09:57 David Demelier said the following: > Yes I have added debugging option in my kernel. I have makeoptions DEBUG=-g in > my config. Do I need more ? .symbols? I don't know how else to explain consistently broken / useless stack traces. > I'm not sure to understand what you meant about stray signatures.. "-- " sequence. Let me show you: -- There is a stray signature sequence above this line. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 09:26:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6DAA3C47 for ; Tue, 12 Feb 2013 09:26:32 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by mx1.freebsd.org (Postfix) with ESMTP id 3078CF4F for ; Tue, 12 Feb 2013 09:26:31 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id 1so2957311qec.5 for ; Tue, 12 Feb 2013 01:26:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SjaSQZU+WRrwdMa8qnwFflkA1xUxD4gHtILBoK0MaHE=; b=UUXRo6EmOosTSYvs/vihC0HXPopIAJZyuUE2wk6rUcEi0D0dv7r6eXDpuVEU8lxsxp DIt/wHtWk1bSOhD6HmIE49zg1p8+F3NgVXDL8flNqwSEWo544ox+RulgU4iOHcsBlhha v1OPX88cHISz+a99cbZevQhesSTrlW02ySSZXkUMh7l7PcqQjo3R/kPem0G20qVLyQ0D g5SVJGMZpj0zDTvRmRSSR1F0c80fyBn7JS8NdpFEHV//SX8VzZBK+5xvBcmW6snmo2vm OuSxt/YofyMjZR1k5Yg3DT8KHRkLsb1X1e4Z8HwYTbNpuXxPJwu6lUOVg5Bovi9gLK6y Nx+g== MIME-Version: 1.0 X-Received: by 10.224.177.8 with SMTP id bg8mr6654867qab.87.1360661191237; Tue, 12 Feb 2013 01:26:31 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Tue, 12 Feb 2013 01:26:31 -0800 (PST) In-Reply-To: <1360626817405-5786129.post@n5.nabble.com> References: <201302111606.06731.jhb@freebsd.org> <1360626817405-5786129.post@n5.nabble.com> Date: Tue, 12 Feb 2013 10:26:31 +0100 X-Google-Sender-Auth: BooEa93qaUYJ7oRA0J_BRH952EA Message-ID: Subject: Re: 9.1-RELEASE AMD64 crash under VBox 4.2.6 when IO APIC is disabled From: CeDeROM To: Jakub Lach 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: Tue, 12 Feb 2013 09:26:32 -0000 On Tue, Feb 12, 2013 at 12:53 AM, Jakub Lach wrote: > As far as I remember, there is no apic option in amd64 kernel, > because it's always included. Yup, I guess that note in the handbook should be updated :-) CPU: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz (2394.03-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x20655 Family = 6 Model = 25 Stepping = 5 Features=0xbfebfbff Features2=0x29ae3ff AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3895271424 (3714 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 5 ACPI Warning: 32/64X FACS address mismatch in FADT - 0xDB36BF40/0x00000000DB36ED40, using 32 (20110527/tbfadt-517) ioapic0 irqs 0-23 on motherboard Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 10:42:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 30A542AE for ; Tue, 12 Feb 2013 10:42:55 +0000 (UTC) (envelope-from p.christias@noc.ntua.gr) Received: from ulysses.noc.ntua.gr (ulysses.noc.ntua.gr [147.102.222.230]) by mx1.freebsd.org (Postfix) with ESMTP id A087B3E0 for ; Tue, 12 Feb 2013 10:42:54 +0000 (UTC) Received: from ajax.noc.ntua.gr (ajax6.noc.ntua.gr [IPv6:2001:648:2000:dc::1]) by ulysses.noc.ntua.gr (8.14.5/8.14.5) with ESMTP id r1CAfakf080391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Feb 2013 12:41:36 +0200 (EET) (envelope-from p.christias@noc.ntua.gr) Received: from ajax.noc.ntua.gr (localhost [127.0.0.1]) by ajax.noc.ntua.gr (8.14.5/8.14.4) with ESMTP id r1CAfa8e061257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Feb 2013 12:41:36 +0200 (EET) (envelope-from p.christias@noc.ntua.gr) Received: (from christia@localhost) by ajax.noc.ntua.gr (8.14.5/8.14.4/Submit) id r1CAfapV061256; Tue, 12 Feb 2013 12:41:36 +0200 (EET) (envelope-from p.christias@noc.ntua.gr) X-Authentication-Warning: ajax.noc.ntua.gr: christia set sender to p.christias@noc.ntua.gr using -f Date: Tue, 12 Feb 2013 12:41:36 +0200 From: Panagiotis Christias To: "John Alex." Subject: Re: Installing FreeBSD 9.1 amd64 on IBM x3550 M3 Message-ID: <20130212104136.GA60946@noc.ntua.gr> References: <20130211112352.GA84742@noc.ntua.gr> <20130211191145.2b96ba8f@X220.ovitrap.com> <51193151.2090204@noc.ntua.gr> <20130212005913.GA33927@neutralgood.org> <5119F531.7030707@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5119F531.7030707@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.5 at ulysses.noc.ntua.gr X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (ulysses.noc.ntua.gr [IPv6:2001:648:2000:de::230]); Tue, 12 Feb 2013 12:41:37 +0200 (EET) Cc: freebsd-stable@freebsd.org, kpneal@pobox.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 10:42:55 -0000 On Tue, Feb 12, 2013 at 09:54:25AM +0200, John Alex. wrote: > > On 02/12/2013 02:59 AM, kpneal@pobox.com wrote: > > On Mon, Feb 11, 2013 at 11:43:55AM -0800, Kevin Oberman wrote: > >> On Mon, Feb 11, 2013 at 9:58 AM, Panagiotis Christias > >> wrote: > >>> > >>> I suppose trying an 8.3 installation would be the easiest way to use MBR > >>> instead of GPT, right; > >> > >> That would do it, but 9.1 is perfectly happy doing MBR. It's just not > >> the default. > >> > >> Seems like many BIOSes assume that GPT=uEFI. Clearly this is silly, but... > >> > >> I know Lenovo laptops have this problem and it is VERY annoying. I run > >> FreeBSD on a GPT disk on my ThinkPad, but I have booteasy installed on > >> an MBR disk (which contains W7) and my BIOS is set to boot from that > >> disk.BootEasy then will boot up the GPT disk with FreeBSD. > > > > Doesn't GPT start with an MBR covering the entire disk? How feasible would > > it be to tweak that MBR so that a boot partition was listed in it? Say, a > > partition holding the root filesystem could be listed in both the GPT and > > MBR style. Then a disk could be booted with MBR or GPT at the whim of the > > firmware. > > > > I agree that this BIOS=MBR/UEFI=GPT assumption is pure rubbish. I've got > > machines with this documented restriction and I'd love a way around it. > > > > It is feasible, it's known as a hybrid MBR. On Linux I've accomplished > this using the gdisk utility, I don't know how it can be done on FreeBSD > though. I had to use this ugly solution in order to install windows 8 on > a GPT disk on a pc without UEFI support. Just for the record, I managed to install successfully 8.3 with the default options and 9.1 by selecting MBR instead of GPT during the initial disk patitioning. In both cases the system's UEFI/BIOS options were left untouched. Thanks for the help, Panagiotis -- Panagiotis J. Christias Network Management Center P.Christias@noc.ntua.gr National Technical Univ. of Athens, GREECE From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 12:11:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C904224B; Tue, 12 Feb 2013 12:11:13 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by mx1.freebsd.org (Postfix) with ESMTP id 66E41A2C; Tue, 12 Feb 2013 12:11:13 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id o13so41275qaj.15 for ; Tue, 12 Feb 2013 04:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1vvF2AlVjSsMOPXTNd1dTp7nljms1c+qMVDxSfM63CE=; b=UoLt4qaLC1MrapMul7KJYiqv9tOwLdCfNBFw180k4rvqAYl6ib5+2R7eE9ViXtmI2/ y2hcz0feA6Cup9x4A4Nj5Ymamru5/0uOCS5BOANcWy0XseFU+AUHVbnQPeaMFlsYM2o8 idRr84rIIF5Rgp36PPQPmB0YLlx/6jvGUWggcQm7yCYMyV3Z7zYHNJcKPHfYh7U2fOFK qryIkM4tAZ3PDEN2Pj8X2XShs7dqeCGXaPumionE5/3NvAXLc0Ha1XLA0TghU9YROjwl I1O++7NcyKC1oB4XPzcO7bGa3zRcMhPhZ4Tqo/nEpxtIBaufk4vGug+JD40U5rdBN9Tg hSrg== MIME-Version: 1.0 X-Received: by 10.224.177.8 with SMTP id bg8mr6813311qab.87.1360671072517; Tue, 12 Feb 2013 04:11:12 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Tue, 12 Feb 2013 04:11:12 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Feb 2013 13:11:12 +0100 X-Google-Sender-Auth: jtI0cE1Rd1ceJ7dR0cqtZe7c-a8 Message-ID: Subject: Re: 9.1 AMD64 multitasking efficiency low From: CeDeROM To: =?UTF-8?Q?Bernhard_Fr=C3=B6hlich?= Content-Type: text/plain; charset=UTF-8 Cc: freebsd-emulation@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, 12 Feb 2013 12:11:13 -0000 On Mon, Feb 11, 2013 at 11:35 PM, CeDeROM wrote: > I can work on VESA xorg driver, I can have no multimedia drivers, but > the system performance is really important factor for me and working > like this is really unpleasant on a pretty modern machine :-( I made a short movie to show how bad this looks :-) After some time of moving data from ext2 sata partition to ufs2 usb partition I have started Xorg, the speed is a disaster, then I have shutdown the Xorg, stopped file transfer and starter Xorg again, things were okay, then started transfer again and things get worse and worse again... http://youtu.be/5pLODViX3JY Now when all of the data are back on the sata drive with UFS2 things seems a lot better. Do you think this may be the EXT2 issue? Still when swap starts working there is a slowdown to the whole system. What are recommended flags to build the kernel for efficiency? Does debug symbols in kernel can slow things down? Any hints welcome! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 13:02:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7C5AA511 for ; Tue, 12 Feb 2013 13:02:04 +0000 (UTC) (envelope-from c47g@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by mx1.freebsd.org (Postfix) with ESMTP id 041ABDAF for ; Tue, 12 Feb 2013 13:02:03 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MEHTC-1U7OAU3fqK-00FVIM for ; Tue, 12 Feb 2013 14:02:02 +0100 Received: (qmail invoked by alias); 12 Feb 2013 13:02:02 -0000 Received: from cm56-168-232.liwest.at (EHLO bones.gusis.at) [86.56.168.232] by mail.gmx.net (mp024) with SMTP; 12 Feb 2013 14:02:02 +0100 X-Authenticated: #9978462 X-Provags-ID: V01U2FsdGVkX1+1REUBMdW1MA8pdUSRQbmizeMwsCb2h/UUMC1WKk oeYbGiKMSV5nKw From: Christian Gusenbauer To: freebsd-stable@freebsd.org Subject: Re: 9.1 AMD64 multitasking efficiency low Date: Tue, 12 Feb 2013 14:04:28 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201302121404.28342.c47g@gmx.at> X-Y-GMX-Trusted: 0 Cc: freebsd-emulation@freebsd.org, Bernhard =?iso-8859-1?q?Fr=F6hlich?= , CeDeROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Feb 2013 13:02:04 -0000 On Tuesday 12 February 2013 13:11:12 CeDeROM wrote: > On Mon, Feb 11, 2013 at 11:35 PM, CeDeROM wrote: > > I can work on VESA xorg driver, I can have no multimedia drivers, but > > the system performance is really important factor for me and working > > like this is really unpleasant on a pretty modern machine :-( > > I made a short movie to show how bad this looks :-) After some time of > moving data from ext2 sata partition to ufs2 usb partition I have > started Xorg, the speed is a disaster, then I have shutdown the Xorg, > stopped file transfer and starter Xorg again, things were okay, then > started transfer again and things get worse and worse again... > > http://youtu.be/5pLODViX3JY > > Now when all of the data are back on the sata drive with UFS2 things > seems a lot better. Do you think this may be the EXT2 issue? Still > when swap starts working there is a slowdown to the whole system. > > What are recommended flags to build the kernel for efficiency? > > Does debug symbols in kernel can slow things down? > > Any hints welcome! :-) > Tomek Hi! Maybe it's hardware related? I experience the same slowness as you do as soon as I copy more than a few MB of data *on the same drive*. It doesn't make any difference if the destination is on the same filesystem or not. When the copy is done, everything is back to normal. Recently I bought a new drive for doing backups which I connect via eSata. Now guess what: copying data on that drive does not affect the performance of the system! But copying data from that drive to the old one renders the machine unusable as soon as the write starts. Here's the dmesg output of my old drive: ada0 at ahcich2 bus 0 scbus2 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: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 and here the one of the new drive: ada1 at ahcich0 bus 0 scbus0 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 My motherboard is an ASUS P5B-E. Do you have an external drive which you can use for a test? Ciao, Christian. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 13:24:15 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 09F53E4E; Tue, 12 Feb 2013 13:24:15 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by mx1.freebsd.org (Postfix) with ESMTP id 7C619ED0; Tue, 12 Feb 2013 13:24:14 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id o13so1656424qaj.12 for ; Tue, 12 Feb 2013 05:24:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=m7LX+RspI9zdD0bnOJqZzriRYQGH4MBMfaDpgehHabw=; b=lf+aPLmF5sSW2IpYNcwMqj7L/V9dbfb/uMYln2UC+0YGxLXtwYSxKhrdP+3L2EOot/ SidBffeqdpzmwprR/BGCCt/I3r05Q5kumS1lxgePCZn+qVGrqQHPw8XvYApVtdG+Ht2i qKBqs+EM/OjXGCDYfdgyKu+t0ZLWrqqSdefOhIe6+WEg/BbWPGWRYtjeND61C8gXObNF smH89P7TP8iqpHXykibuhdR3c+tPBzFq7fqku6YiiyrOK78nsHWf4GUbbZpmYLc3h/hX QCm8fnJV5LBrdBpJOpl0zBvQHA6Ser+WH9w9u5ITu+e2o+GHTMgfqR3xb2dyL5ZspPMd lmyw== MIME-Version: 1.0 X-Received: by 10.224.222.15 with SMTP id ie15mr7180088qab.75.1360675044593; Tue, 12 Feb 2013 05:17:24 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Tue, 12 Feb 2013 05:17:24 -0800 (PST) In-Reply-To: <201302121404.28342.c47g@gmx.at> References: <201302121404.28342.c47g@gmx.at> Date: Tue, 12 Feb 2013 14:17:24 +0100 X-Google-Sender-Auth: Qg0HOAkb48fExR3XT8E52K2MqvI Message-ID: Subject: Re: 9.1 AMD64 multitasking efficiency low From: CeDeROM To: Christian Gusenbauer Content-Type: text/plain; charset=UTF-8 Cc: =?UTF-8?Q?Bernhard_Fr=C3=B6hlich?= , freebsd-emulation@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, 12 Feb 2013 13:24:15 -0000 On Tue, Feb 12, 2013 at 2:04 PM, Christian Gusenbauer wrote: > Maybe it's hardware related? I experience the same slowness as you do as soon > as I copy more than a few MB of data *on the same drive*. (...) Hello Christian :-) Thank you for your feedback! :-) There was no problem today to copy from internal ufs2 to external ufs2, but I have tried to copy back from external (ufs2) to internal (ufs2) and guess what - I got the terrible slowdown!!! Just when I hit Ctrl+C things get back to normal right away.. so the problem is with writing to the WDC SATA drive... Is it something wrong with the mass storage / ahci / sata driver? Yesterday I have switched the SATA from RAID to AHCI mode, but this seems to change nothing. Is it something wrong with the WDC drives? :-\ Internal drive: 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: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 External drive: da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 305245MB (625142448 512 byte sectors: 255H 63S/T 38913C) Thank you!! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 13:24:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C2B23F7E; Tue, 12 Feb 2013 13:24:30 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by mx1.freebsd.org (Postfix) with ESMTP id 614EFED7; Tue, 12 Feb 2013 13:24:30 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id v28so24687qcm.11 for ; Tue, 12 Feb 2013 05:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=R1q+fvSyPOTgC7Hlx3UXMyaZQzWPW3ZHvWbsoU5OK3c=; b=TD/6oz7/aEs3ExxC4i3XUFGZDqnBcLeU0hnDHCQtOW2dbGmGdJSutuhoK+w6xLlv34 XRLYhu2x4Z3Lrvj4u5I4/04WEcXb8uBwOdsaTOmvbuPyHVjVsPmVLB0KVvuOLo8n6yYA oSGN3B7J7OkKOjLBTWKfTX1YxZVFRtoDfgQYUUOwpaElOmKWxYphiNPydPpC/iLzvvV4 F59awDQRjJebsoNLdKezfk+OLTAG13yX33Rl0g/AlUClMecVQp6jULeBzK6e9UOlrxpx 7RhrOUO+DVzzp35VHOxnhVLE+YfAdf8MT149DYPLv1uQZrrXjwVwtDYjLsPhyx6H0tQl 48LQ== MIME-Version: 1.0 X-Received: by 10.224.209.193 with SMTP id gh1mr7012470qab.86.1360675464593; Tue, 12 Feb 2013 05:24:24 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Tue, 12 Feb 2013 05:24:24 -0800 (PST) In-Reply-To: References: <201302121404.28342.c47g@gmx.at> Date: Tue, 12 Feb 2013 14:24:24 +0100 X-Google-Sender-Auth: igIj1DJM9u5HCZsBg9Nb6UvignY Message-ID: Subject: Re: 9.1 AMD64 multitasking efficiency low From: CeDeROM To: Christian Gusenbauer Content-Type: text/plain; charset=UTF-8 Cc: =?UTF-8?Q?Bernhard_Fr=C3=B6hlich?= , freebsd-emulation@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, 12 Feb 2013 13:24:30 -0000 On Tue, Feb 12, 2013 at 2:17 PM, CeDeROM wrote: > On Tue, Feb 12, 2013 at 2:04 PM, Christian Gusenbauer wrote: >> Maybe it's hardware related? I experience the same slowness as you do as soon >> as I copy more than a few MB of data *on the same drive*. (...) > > Hello Christian :-) Thank you for your feedback! :-) There was no > problem today to copy from internal ufs2 to external ufs2, but I have > tried to copy back from external (ufs2) to internal (ufs2) and guess > what - I got the terrible slowdown!!! Just when I hit Ctrl+C things > get back to normal right away.. so the problem is with writing to the > WDC SATA drive... I also noticed that issue on a far more powerful machine and the WDC 2TB drive. At first I thought the drive was broken, then I switched from ext2 to ufs2 that improved efficiency to an acceptable level, but still it does not look as it should, maybe something wrong with the SATA(2) driver or the WDC drives :-) Glad to hear I am not alone, thanks!! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 14:47:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C996690B; Tue, 12 Feb 2013 14:47:30 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 61FDC8E7; Tue, 12 Feb 2013 14:47:29 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id r1CEqVMe088323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2013 15:52:32 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <511A55F9.4080205@omnilan.de> Date: Tue, 12 Feb 2013 15:47:21 +0100 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, freebsd-jail@freebsd.org Subject: problem stoping jails with jail(8), jail.conf and mount.fstab X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE4115EB90526EFB833D1814D" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Feb 2013 14:47:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE4115EB90526EFB833D1814D Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, on 9.1-R, I highly appreciate the new jail(8) and jail.conf capabilities. Thanks for that extension! But I have one problem: If I want to stop a jail with 'jaill -r jailname', I get "umount: unmount of /.jail.jailname failed: Device busy"= It seems to me that the order of fstab.jailname entries are not reverted by jail(8) when shutting down/umounting. My C skills don't allow me to verify/fix that in usr.sbin/jail/command.c Can anybody help please? Thanks, -Harry (not subscribed to jail@) --------------enigE4115EB90526EFB833D1814D 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) iEYEARECAAYFAlEaVfkACgkQLDqVQ9VXb8i7qQCdEXO2f61R585GKuJwhZj26wA9 E3EAnRNeOdgmMmOwgdg7p6TSJBNQmBow =GRuO -----END PGP SIGNATURE----- --------------enigE4115EB90526EFB833D1814D-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 14:58:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E477CD58; Tue, 12 Feb 2013 14:58:50 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7E29A3; Tue, 12 Feb 2013 14:58:49 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id r1CF3x77088542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2013 16:03:59 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <511A58A8.50703@omnilan.de> Date: Tue, 12 Feb 2013 15:58:48 +0100 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, freebsd-jail@freebsd.org Subject: Re: problem stoping jails with jail(8), jail.conf and mount.fstab References: <511A55F9.4080205@omnilan.de> In-Reply-To: <511A55F9.4080205@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDBA6D07CE516CA02A636B3B1" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Feb 2013 14:58:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDBA6D07CE516CA02A636B3B1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable schrieb Harald Schmalzbauer am 12.02.2013 15:47 (localtime): > Hello, > > on 9.1-R, I highly appreciate the new jail(8) and jail.conf > capabilities. Thanks for that extension! > > But I have one problem: If I want to stop a jail with 'jaill -r > jailname', I get "umount: unmount of /.jail.jailname failed: Device bus= y" > > It seems to me that the order of fstab.jailname entries are not reverte= d > by jail(8) when shutting down/umounting. > My C skills don't allow me to verify/fix that in usr.sbin/jail/command.= c Btw, experimental falsifying isn't the problem: fstab.jail1: /dev/gpt/jail1ROOT /.jail.jail1 ufs ro 0 0 /dev/gpt/jail1VAR /.jail.jail1/var ufs rw,noatime 0 0 Starting jail with 'jail -c jail1': everything fine. Stoping jail with 'jail -r jail1': error when fstab.jail1 is like above, but error vanishes if I revert the two lines above before stoping! So the root cause seems to be obvious. But like mentioned, I can't fix that myself :-( Thanks, -Harry --------------enigDBA6D07CE516CA02A636B3B1 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) iEYEARECAAYFAlEaWKkACgkQLDqVQ9VXb8gXqQCfao/pVXU0L61n3gh2nNr+Sx+h aG8Anjzj3xaXJz/hSmbOZZHXu0agge+e =q8WV -----END PGP SIGNATURE----- --------------enigDBA6D07CE516CA02A636B3B1-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 15:21:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E98824AA for ; Tue, 12 Feb 2013 15:21:53 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id A5677AB9 for ; Tue, 12 Feb 2013 15:21:53 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by kabab.cs.huji.ac.il with esmtp id 1U5Hg8-0007wo-5r for freebsd-stable@freebsd.org; Tue, 12 Feb 2013 17:21:52 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-stable@freebsd.org Subject: ix? / Intel(R) PRO/10GbE Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Feb 2013 17:21:52 +0200 From: Daniel Braniss Message-ID: X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 15:21:54 -0000 I finally got a 10G card that is recognized by FreeBSD (9.1-stable): ... ix0: port 0xecc0-0xecdf mem 0xd9e80000-0xd9efffff,0xd9ff8000-0xd9ffbfff irq 40 at device 0.0 on pci4 ix0: Using MSIX interrupts with 9 vectors ix0: RX Descriptors exceed system mbuf max, using default instead! ix0: Ethernet address: 90:e2:ba:29:c0:54 ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 ... but it apperas as ix0/ix1, manuals only mention ixgb/e, and ifconfig: ix0: flags=8802 metric 0 mtu 1500 options=401bb ether 90:e2:ba:29:c0:54 nd6 options=21 media: Ethernet autoselect status: no carrier ix1: flags=8802 metric 0 mtu 1500 options=401bb ether 90:e2:ba:29:c0:55 nd6 options=21 media: Ethernet autoselect status: no carrier and pciconf: ix0@pci0:4:0:0: class=0x020000 card=0x7a118086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' class = network subclass = ethernet Secondly how is this fixable: RX Descriptors exceed system mbuf max, using default instead! thanks, danny From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 15:27:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AAC456F1 for ; Tue, 12 Feb 2013 15:27:52 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 172FBB12 for ; Tue, 12 Feb 2013 15:27:51 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg6so211815lbb.13 for ; Tue, 12 Feb 2013 07:27:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xya68ssR4nv9liqpPMcpxpIkOx9wXtqwBK0MNynRlo8=; b=Vu5gcjVSsdl5Oni4SBGfyDWYCWamvDLoV7+7jcZK3Srkm+0JIzwEm9pvBGmJHqB6bm M/iJyLQ2KWiXuQFcxu1MSrd+gPbCRx73ECSGfvHWTqOuvy+9CjCmZsT4BTjXdaFtqCiD SsnAfgpZYe1V/6igUO38k9P9yb97zUzkzdC8T9cc59XnvIwhY/jB1xlRNKBZulxeAiH+ ULJjCskFQVmDpWQI5Z5saaHD/+N9fKsuPV7kj1oYulWfpRtFStDt0oEnAwaO9ZbGIOwW Pos8pJ4Vu4qCHQHkTh180WB4yGQrs7H9QxoqcJAKF2JXOsAaSmxobDY3vdgB5oT5OfTZ EYwA== MIME-Version: 1.0 X-Received: by 10.152.148.133 with SMTP id ts5mr5215741lab.2.1360682870684; Tue, 12 Feb 2013 07:27:50 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.3.36 with HTTP; Tue, 12 Feb 2013 07:27:50 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Feb 2013 07:27:50 -0800 X-Google-Sender-Auth: 4ijXTcd5GFgYgnsQu2t3nhCnzOM Message-ID: Subject: Re: ix? / Intel(R) PRO/10GbE From: Luigi Rizzo To: Daniel Braniss Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 15:27:52 -0000 ixgbe is the _driver name_, ix is the _interface name_ you see in ifconfig. The latter is usually shorter. Also there are overlaps, e.g. the lem, em and igb drivers all map to "em" as interface name. cheers luigi On Tue, Feb 12, 2013 at 7:21 AM, Daniel Braniss wrote: > I finally got a 10G card that is recognized by FreeBSD (9.1-stable): > ... > ix0: port > 0xecc0-0xecdf mem 0xd9e80000-0xd9efffff,0xd9ff8000-0xd9ffbfff irq 40 at > device > 0.0 on pci4 > ix0: Using MSIX interrupts with 9 vectors > ix0: RX Descriptors exceed system mbuf max, using default instead! > ix0: Ethernet address: 90:e2:ba:29:c0:54 > ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 > ... > but it apperas as ix0/ix1, manuals only mention ixgb/e, > and ifconfig: > > ix0: flags=8802 metric 0 mtu 1500 > > options=401bb UM,TSO4,VLAN_HWTSO> > ether 90:e2:ba:29:c0:54 > nd6 options=21 > media: Ethernet autoselect > status: no carrier > ix1: flags=8802 metric 0 mtu 1500 > > options=401bb UM,TSO4,VLAN_HWTSO> > ether 90:e2:ba:29:c0:55 > nd6 options=21 > media: Ethernet autoselect > status: no carrier > > and pciconf: > ix0@pci0:4:0:0: class=0x020000 card=0x7a118086 chip=0x10fb8086 rev=0x01 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' > class = network > subclass = ethernet > > Secondly how is this fixable: > RX Descriptors exceed system mbuf max, using default instead! > > thanks, > danny > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 15:31:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DA11A84C for ; Tue, 12 Feb 2013 15:31:03 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 9A98BB48 for ; Tue, 12 Feb 2013 15:31:03 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa07.fnfis.com (8.14.5/8.14.5) with ESMTP id r1CFUi5o014358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Feb 2013 09:30:46 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.02.0309.002; Tue, 12 Feb 2013 09:30:45 -0600 From: "Teske, Devin" To: Daniel Braniss , "freebsd-stable@freebsd.org" Subject: RE: ix? / Intel(R) PRO/10GbE Thread-Topic: ix? / Intel(R) PRO/10GbE Thread-Index: AQHOCTS51RZcgQACiESvcPSCI1tHdZh2WHTB Date: Tue, 12 Feb 2013 15:30:44 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201EA7586@ltcfiswmsgmb21> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-02-12_05:2013-02-12,2013-02-12,1970-01-01 signatures=0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 15:31:03 -0000 On Tue, 12 Feb 2013, Daniel Braniss wrote: > I finally got a 10G card that is recognized by FreeBSD (9.1-stable): > ... > ix0: port > 0xecc0-0xecdf mem 0xd9e80000-0xd9efffff,0xd9ff8000-0xd9ffbfff irq 40 at d= evice > 0.0 on pci4 > ix0: Using MSIX interrupts with 9 vectors > ix0: RX Descriptors exceed system mbuf max, using default instead! > ix0: Ethernet address: 90:e2:ba:29:c0:54 > ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 > ... > but it apperas as ix0/ix1, manuals only mention ixgb/e, > and ifconfig: >=20 > ix0: flags=3D8802 metric 0 mtu 1500 > options=3D401bb UM,TSO4,VLAN_HWTSO> > ether 90:e2:ba:29:c0:54 > nd6 options=3D21 > media: Ethernet autoselect > status: no carrier > ix1: flags=3D8802 metric 0 mtu 1500 > options=3D401bb UM,TSO4,VLAN_HWTSO> > ether 90:e2:ba:29:c0:55 > nd6 options=3D21 > media: Ethernet autoselect > status: no carrier >=20 > and pciconf: > ix0@pci0:4:0:0: class=3D0x020000 card=3D0x7a118086 chip=3D0x10fb8086 rev= =3D0x01 > hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82599EB 10-Gigabit SFI/SFP+ Network Connection' > class =3D network > subclass =3D ethernet >=20 > Secondly how is this fixable: > RX Descriptors exceed system mbuf max, using default instead! >=20 >From reading sys/dev/ixgbe/README: echo "kern.ipc.nmbclusters=3D262144" >> /etc/sysctl.conf echo "kern.ipc.nmbjumbop=3D262144" >> /etc/sysctl.conf reboot --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 17:09:34 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ED3E9A08 for ; Tue, 12 Feb 2013 17:09:34 +0000 (UTC) (envelope-from bharper@chaosweb.us) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 7CEAE268 for ; Tue, 12 Feb 2013 17:09:34 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id ec20so307009lab.37 for ; Tue, 12 Feb 2013 09:09:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=tJ81FVLnfqbm7sWyEI0MeA8z39rdt1KTObJQEWAvDzk=; b=FwXiXxbA6B+7hOTe9oSOb3SnpmNBg39mgfqL+IJ9VKZ2hfClt/0E37WoT8Bq7so6Sw XgV43AWYYRUyULCWJdH3294k3S4A8b1cF3ecwpA1wouK6y7sBBivQVPT3UL6YoWqID2f o4kqFvTRzMMbPbfSmq9cg2HM+IxQCF5TSSTFkUrJqOZ1g9KUfw6nPXgVHIAIUso4wi9Z nL+eeqoMfAdmUvUjT30/do0OinNewTiYt0dPCePtTZ3eq6HNPklbxB/DVsrGcYesJ9Sq McY5kMfXlHPrSO567K2em4ZMGeUj6/psLdRz/M2ybkeUAA2lbR00QxRBzqyUF+3IsvjY D+GA== X-Received: by 10.112.44.164 with SMTP id f4mr7646313lbm.43.1360688973167; Tue, 12 Feb 2013 09:09:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.39.101 with HTTP; Tue, 12 Feb 2013 09:09:13 -0800 (PST) X-Originating-IP: [173.14.206.193] From: Branden Harper Date: Tue, 12 Feb 2013 11:09:13 -0600 Message-ID: Subject: Random reboot / Crash(?) on AMD Sempron with 9.1-R To: freebsd-stable@freebsd.org X-Gm-Message-State: ALoCoQkFfhlPVHmi1tPXwJ3C+mq6Qk3jEyFq0Tow6YuUKS45k9cNIYN70TzPXheB+8ZuUscMS8kK 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, 12 Feb 2013 17:09:35 -0000 Hello, I'm having an issue with my AMD Sempron box. It randomly crashes/reboots. I have no been able to catch it in the act, I just find the aftermath the next time I log in. It does not drop any core files in /var/crash and has no strange messages in the log files. I have even built a custom kernel with KDB and KDB_UNATTENDED options, but there seems to be no traces. Any tips/help is appreciated. If more info is needed I will provide what I can. Server Information - FreeBSD chloe 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Mon Feb 11 15:47:59 CST 2013 root@chloe:/usr/src/sys/i386/compile/CHLOE i386 CPU: AMD Sempron(tm) 2300+ (1579.41-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Family = 6 Model = 8 Stepping = 1 Features=0x383fbff AMD Features=0xc0480800 real memory = 805306368 (768 MB) avail memory = 731676672 (697 MB) Motherboard: ECS 741GX-m ( http://www.ecs.com.tw/ECSWebSite/Product/Product_Detail.aspx?DetailID=422&MenuID=1&LanID=0 ) From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 17:12:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7659DB64 for ; Tue, 12 Feb 2013 17:12:28 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 479A329C for ; Tue, 12 Feb 2013 17:12:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1CHCRK5025751 for ; Tue, 12 Feb 2013 17:12:27 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1CHCRiR025750 for freebsd-stable@freebsd.org; Tue, 12 Feb 2013 17:12:27 GMT (envelope-from bdrewery) Received: (qmail 31408 invoked from network); 12 Feb 2013 11:12:26 -0600 Received: from unknown (HELO ?192.168.0.74?) (freebsd@shatow.net@74.94.87.209) by sweb.xzibition.com with ESMTPA; 12 Feb 2013 11:12:26 -0600 Message-ID: <511A77F9.2020009@FreeBSD.org> Date: Tue, 12 Feb 2013 11:12:25 -0600 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ruben de Groot Subject: Re: MFC openssh fix versionaddendum? References: <20130211120501.GA23676@eris.bzerk.org> In-Reply-To: <20130211120501.GA23676@eris.bzerk.org> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2PGMCPMQSXHPVVOPCVPIR" 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, 12 Feb 2013 17:12:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2PGMCPMQSXHPVVOPCVPIR Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/11/2013 6:05 AM, Ruben de Groot wrote: >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D163843 >=20 > The fix was committed to -current, but in 9.1 it's still not working. >=20 > cheersRuben I plan to also add this back into the security/openssh-portable port soon= =2E --=20 Regards, Bryan Drewery bdrewery@freenode/EFNet ------enig2PGMCPMQSXHPVVOPCVPIR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRGnf9AAoJEG54KsA8mwz5t4cQAJw+0MNPHJHSxMVYvdKqOjAY xjXyVCcyamrYQU98kY+4oUzwCIGRfRKvagERSawZEeIETPxO1oXIB7dX+41a+lbN 0xwdcIoxr0jRdNt1SMeKefJjchR2zkTWzcL7GBfHgbmImIEIhXQuuVQw0dOANI3Q nP/TNjYhsuRH+bFFTb7K5csOyk+VgT/BkYaNtMyUXa22SdMMSWadRZEZ9yEaPpuU o+dMDILGLVxePoU8Bar6OSXH3NF8LKmudMgt0CjqAKe5NcooErwn0IngZ3aw9HS5 888QHewp8VcXGIKVIKCLCZC5fj19X2GVkJYVDnxIb/kXKPeObEieBzFQP2K/Cg8k 2VTJMYwcZ0SQjSP+2WfpwJM1AMIPPjw9mdj/YXgZ42MeXluFzlQS6Obh3+zWrQYX 9VkRoJyc4i4FWwg4HHt7lMwKsDDApf953+QRUo+DiLC7gQKKkBvNYPVsMP4O7GnB T9QREH5Vj3N/XyvJqkiNlHTH+N329RLwO2RboDfXDbDba+kX1NGGaQGjGdSxxx0K 9hhPSlPlLt9BQHLO/czp/ODSqPKXpdcWVAC4IXdDZmPOl8klMmlmFBr4sa2IEdpX 4B5AueBg1W03RsRVofcUhwy/0uXE6NBH0OhWmUfUAr0Q/2ipLzvu/McLf7QbZCmY ZH2QHeF3FPe6ev2jsHbl =9eTj -----END PGP SIGNATURE----- ------enig2PGMCPMQSXHPVVOPCVPIR-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 17:38:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D0033357 for ; Tue, 12 Feb 2013 17:38:27 +0000 (UTC) (envelope-from traveling08@cox.net) Received: from fed1rmwml114.cox.net (fed1wml22.cox.net [68.230.241.21]) by mx1.freebsd.org (Postfix) with ESMTP id 91B7D3DE for ; Tue, 12 Feb 2013 17:38:26 +0000 (UTC) Received: from fed1rmimpo209 ([68.230.241.160]) by fed1rmfepo202.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130212155318.TFLE1243.fed1rmfepo202.cox.net@fed1rmimpo209> for ; Tue, 12 Feb 2013 10:53:18 -0500 Received: from zorro ([72.220.112.133]) by fed1rmimpo209 with cox id zTtH1k00N2skfVC01TtH27; Tue, 12 Feb 2013 10:53:18 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020206.511A656E.0014,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=ZKBVaAHb c=1 sm=1 a=blkYnWlwlWmjWY/ySXj5BQ==:17 a=DulnUioUdl0A:10 a=G8Uczd0VNMoA:10 a=kj9zAlcOel0A:10 a=kviXuzpPAAAA:8 a=6b-rTLirIi4A:10 a=tZoK9wWy2idXm9X5hYYA:9 a=CjuIK1q_8ugA:10 a=blkYnWlwlWmjWY/ySXj5BQ==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Date: Tue, 12 Feb 2013 07:53:17 -0800 From: Robert To: freebsd-stable@freebsd.org Subject: Cant remove raid from Hard drive Message-ID: <20130212075317.002dd257@zorro> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) 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: Tue, 12 Feb 2013 17:38:27 -0000 Greetings I am trying to reuse a 500G harddrive that was previously part of an NVIDIA raid in a windows box. I have tried to clean the disk using "dd if=/dev/zero of=/dev/raid/r0 bs=1m". The dd program completed but the raid info is still on the disk, I was able to set up the disk with gpart create -s gpt /dev/raid/r0 gpart add -t freebsd-ufs -l 500Gig -b 1M newfs -U /dev/gpt/500Gig I can mount and use the disk but it still shows up at /dev/raid/r0 and my dmesg is spammed with GEOM_RAID: NVIDIA-1: Array NVIDIA-1 created. Root mount waiting for: GRAID-NVIDIA Root mount waiting for: GRAID-NVIDIA Root mount waiting for: GRAID-NVIDIA Root mount waiting for: GRAID-NVIDIA Root mount waiting for: GRAID-NVIDIA Root mount waiting for: GRAID-NVIDIA until it times out or I hit ^c uname -a FreeBSD zorro.shasta204.local 9.1-STABLE FreeBSD 9.1-STABLE #1 r246453: Thu Feb 7 11:52:20 PST 2013 root@zorro.shasta204.local:/usr/obj/usr/src/sys/GENERIC amd64 Any help greatly appreciated. Robert From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 17:44:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1216783E for ; Tue, 12 Feb 2013 17:44:45 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id 8D1A46A6 for ; Tue, 12 Feb 2013 17:44:44 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hm14so4731478wib.15 for ; Tue, 12 Feb 2013 09:44:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=WWhkYOCtvvyjKgZ3LtwoLfhUl6Qv976c+eDK4/+LNC8=; b=gOpf7IkyIK4qGMmHN9w3FHqgVBLv7PIrtxzNfVXcs5M+o8Zkq9geV8kUMob9QET/uU hlv3fPLcVjrCbbK/TtYx/ipKdzE5MNshu94jYugz/IY8nlvbeLyemejrgploPe3jWymC akmlkXyhBcp+YZAEpT5iqVwL96vKdAAWOCwjWwTDdMflYK1sTTtnghRkFEOQMa5ILya3 IO9CKeLlpu7xny7yQNTllWVgcMTg46kX+o/ZlFruDTovbwEbyG5hkNPDD8uXmBCc1UM9 lRC+m3zzFm7VCnm+yVEZQtG1oG3GoAmDezFXqkmQalBtgRLfrLCB38hdeIcBnrjVT3lz a08Q== X-Received: by 10.194.178.33 with SMTP id cv1mr32745941wjc.46.1360691083642; Tue, 12 Feb 2013 09:44:43 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id e6sm41097253wiz.1.2013.02.12.09.44.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 09:44:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Cant remove raid from Hard drive From: Fleuriot Damien In-Reply-To: <20130212075317.002dd257@zorro> Date: Tue, 12 Feb 2013 18:44:36 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20130212075317.002dd257@zorro> To: Robert X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmnNe+BjG19VdWi4D0rCrV7uKRjjXdH6dMUvu41exKPIQtReeXPLy83hOnZMVgkJxtCjfk/ 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, 12 Feb 2013 17:44:45 -0000 On Feb 12, 2013, at 4:53 PM, Robert wrote: > Greetings > > I am trying to reuse a 500G harddrive that was previously part of an > NVIDIA raid in a windows box. > > I have tried to clean the disk using "dd if=/dev/zero of=/dev/raid/r0 > bs=1m". The dd program completed but the raid info is still on the disk, > I was able to set up the disk with > > gpart create -s gpt /dev/raid/r0 > gpart add -t freebsd-ufs -l 500Gig -b 1M > newfs -U /dev/gpt/500Gig > > I can mount and use the disk but it still shows up at /dev/raid/r0 and > my dmesg is spammed with > > GEOM_RAID: NVIDIA-1: Array NVIDIA-1 created. > Root mount waiting for: GRAID-NVIDIA > Root mount waiting for: GRAID-NVIDIA > Root mount waiting for: GRAID-NVIDIA > Root mount waiting for: GRAID-NVIDIA > Root mount waiting for: GRAID-NVIDIA > Root mount waiting for: GRAID-NVIDIA > > until it times out or I hit ^c > > uname -a > FreeBSD zorro.shasta204.local 9.1-STABLE FreeBSD 9.1-STABLE #1 r246453: > Thu Feb 7 11:52:20 PST 2013 > root@zorro.shasta204.local:/usr/obj/usr/src/sys/GENERIC amd64 > > Any help greatly appreciated. > > Robert graid list From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 17:49:14 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A7A12B0F for ; Tue, 12 Feb 2013 17:49:14 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 45B3D72D for ; Tue, 12 Feb 2013 17:49:13 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r1CHn5IC074682; Wed, 13 Feb 2013 00:49:05 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <511A808C.5020805@rdtc.ru> Date: Wed, 13 Feb 2013 00:49:00 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Robert Subject: Re: Cant remove raid from Hard drive References: <20130212075317.002dd257@zorro> In-Reply-To: <20130212075317.002dd257@zorro> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit 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, 12 Feb 2013 17:49:14 -0000 12.02.2013 22:53, Robert ÐÉÛÅÔ: > Greetings > > I am trying to reuse a 500G harddrive that was previously part of an > NVIDIA raid in a windows box. > > I have tried to clean the disk using "dd if=/dev/zero of=/dev/raid/r0 > bs=1m". The dd program completed but the raid info is still on the disk, That's because RAID metadata is stored outside RAID itself (/dev/raid/r0), it occupies last sectors of physical disks. It can be erased with "graid delete" command, please read man graid. You need operate on its "Geom name" from "graid list | fgrep Geom" command, not on symbolic name /dev/raid/r0. You may also need -f flag (again, read man graid). Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 18:45:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6C2ABD3; Tue, 12 Feb 2013 18:45:45 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by mx1.freebsd.org (Postfix) with ESMTP id D68E19EC; Tue, 12 Feb 2013 18:45:44 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id l13so4804925wie.2 for ; Tue, 12 Feb 2013 10:45:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=N8Mbp7M13BDJVCggNpkUYCLe9VX1BFxqg/sU9xu2tgE=; b=XOrZaudMI7b+GkyK39Y8DUxu2HlxaDXOl8tAXiJGJneaWGHUAhf0yFSH8MPbn//1Xm u5gmNT/CXFG2KTl7AmcApByUxnHYf2VjWl9qwTZNSYGvM6jnyD5fVs2AK4mnQIhNWGGl q86mYR+7/r4nVrYvBJELKx1yJKTjqch6h1VVAyMI3B5ECgqt/JwsGG7/svyjA1GWiJIr 24n42ZFKjvknvQsqWkmLfm90dAN2Nu17FIkc8tkS0QPUYMI5x0UJBsMEMtAjQ6FzfA1H b75zZO5ogXGWTPVXmhsicRWHfhOql9gw0r/J4G8RD2uB1ABaBz6a73YQ8z4rMsHR6nKr wncw== X-Received: by 10.194.58.175 with SMTP id s15mr32960426wjq.31.1360694737543; Tue, 12 Feb 2013 10:45:37 -0800 (PST) Received: from melon.malikania.fr (177.33.91.91.rev.sfr.net. [91.91.33.177]) by mx.google.com with ESMTPS id m6sm41448395wic.2.2013.02.12.10.45.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 12 Feb 2013 10:45:36 -0800 (PST) From: David Demelier To: Andriy Gapon Subject: Re: Panic at shutdown Date: Tue, 12 Feb 2013 19:44:49 +0100 Message-ID: <2872289.1yXr0e1VeO@melon.malikania.fr> User-Agent: KMail/4.9.5 (FreeBSD/9.1-STABLE; KDE/4.9.5; amd64; ; ) In-Reply-To: <5119F6C6.8010802@FreeBSD.org> References: <51127767.1030007@gmail.com> <5119F6C6.8010802@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 18:45:45 -0000 Le mardi 12 f=E9vrier 2013 10:01:10 Andriy Gapon a =E9crit : > on 12/02/2013 09:57 David Demelier said the following: > > Yes I have added debugging option in my kernel. I have makeoptions > > DEBUG=3D-g in my config. Do I need more ? >=20 > .symbols? I don't understand what you are saying, I have /boot/kernel/kernel.symb= ols.=20 Please tell me what I'm doing wrong. I've just read and done the steps = written=20 there : http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug- gdb.html So I've run=20 # cd /usr/obj/usr/src/sys/Melon # kgdb kernel.debug /var/crash/vmcore.0 and that's the only trace I get using bt full : 229 #define IS_BSP() (PCPU_GET(cpuid) =3D=3D 0) (kgdb) bt full #0 doadump (textdump=3D) at pcpu.h:229 No locals. #1 0x0000000000000000 in ?? () No symbol table info available. -- David Demelier From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 19:02:34 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6AFA85BC for ; Tue, 12 Feb 2013 19:02:34 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 63F4EAB5 for ; Tue, 12 Feb 2013 19:02:33 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA26652; Tue, 12 Feb 2013 21:02:29 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <511A91C5.7010502@FreeBSD.org> Date: Tue, 12 Feb 2013 21:02:29 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130206 Thunderbird/17.0.2 MIME-Version: 1.0 To: David Demelier Subject: Re: Panic at shutdown References: <51127767.1030007@gmail.com> <5119F6C6.8010802@FreeBSD.org> <2872289.1yXr0e1VeO@melon.malikania.fr> In-Reply-To: <2872289.1yXr0e1VeO@melon.malikania.fr> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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, 12 Feb 2013 19:02:34 -0000 on 12/02/2013 20:44 David Demelier said the following: > Le mardi 12 février 2013 10:01:10 Andriy Gapon a écrit : >> on 12/02/2013 09:57 David Demelier said the following: >>> Yes I have added debugging option in my kernel. I have makeoptions >>> DEBUG=-g in my config. Do I need more ? >> >> .symbols? > > I don't understand what you are saying, I have /boot/kernel/kernel.symbols. > Please tell me what I'm doing wrong. I've just read and done the steps written > there : > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug- > gdb.html > > So I've run > > # cd /usr/obj/usr/src/sys/Melon > # kgdb kernel.debug /var/crash/vmcore.0 > > and that's the only trace I get using bt full : > > 229 #define IS_BSP() (PCPU_GET(cpuid) == 0) > (kgdb) bt full > #0 doadump (textdump=) at pcpu.h:229 > No locals. > #1 0x0000000000000000 in ?? () > No symbol table info available. I don't know what you are doing wrong, but the above message ("No symbol table info available") is wrong. Perhaps your world (kgdb) and kernel are out of sync, maybe something else... -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 19:46:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9413D1A1 for ; Tue, 12 Feb 2013 19:46:29 +0000 (UTC) (envelope-from traveling08@cox.net) Received: from fed1rmfepi104.cox.net (fed1rmfepi104.cox.net [68.230.241.135]) by mx1.freebsd.org (Postfix) with ESMTP id 424CBD94 for ; Tue, 12 Feb 2013 19:46:28 +0000 (UTC) Received: from fed1rmimpo210 ([68.230.241.161]) by fed1rmfepo203.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130212182544.GUYN23677.fed1rmfepo203.cox.net@fed1rmimpo210> for ; Tue, 12 Feb 2013 13:25:44 -0500 Received: from zorro ([72.220.112.133]) by fed1rmimpo210 with cox id zWRk1k00E2skfVC01WRkDt; Tue, 12 Feb 2013 13:25:44 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A02020A.511A8928.00D2,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=WqmpwKjv c=1 sm=1 a=blkYnWlwlWmjWY/ySXj5BQ==:17 a=gH2l33NO9zgA:10 a=5qrSwuegvzYA:10 a=G8Uczd0VNMoA:10 a=Fdkxr_5KmFUA:10 a=kviXuzpPAAAA:8 a=lLJ2rcPlMxAA:10 a=wsVcy7WDAAAA:8 a=Cf8mFsOASJQ61YzDf_wA:9 a=pvA44qeTxYYA:10 a=blkYnWlwlWmjWY/ySXj5BQ==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Date: Tue, 12 Feb 2013 10:25:44 -0800 From: Robert To: Eugene Grosbein Subject: SOLVED: Cant remove raid from Hard drive Message-ID: <20130212102544.5afce808@zorro> In-Reply-To: <511A808C.5020805@rdtc.ru> References: <20130212075317.002dd257@zorro> <511A808C.5020805@rdtc.ru> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit 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, 12 Feb 2013 19:46:29 -0000 On Wed, 13 Feb 2013 00:49:00 +0700 Eugene Grosbein wrote: > 12.02.2013 22:53, Robert ÐÉÛÅÔ: > > Greetings > > > > I am trying to reuse a 500G harddrive that was previously part of an > > NVIDIA raid in a windows box. > > > > I have tried to clean the disk using "dd if=/dev/zero > > of=/dev/raid/r0 bs=1m". The dd program completed but the raid info > > is still on the disk, > > That's because RAID metadata is stored outside RAID itself > (/dev/raid/r0), it occupies last sectors of physical disks. It can be > erased with "graid delete" command, please read man graid. You need > operate on its "Geom name" from "graid list | fgrep Geom" command, > not on symbolic name /dev/raid/r0. You may also need -f flag (again, > read man graid). > > Eugene Grosbein Eugene Thanks for the response. graid delete raid/r0 removed the raid and works perfect. Thanks for the quick answer. Robert From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 20:15:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4D10B5FD; Tue, 12 Feb 2013 20:15:32 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wg0-x229.google.com (wg-in-x0229.1e100.net [IPv6:2a00:1450:400c:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id 72796E9E; Tue, 12 Feb 2013 20:15:31 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id ds1so3636592wgb.0 for ; Tue, 12 Feb 2013 12:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=b3YdI44yrJSte8EHeZ4LUtc6e+bLmcBEzqVVY27GEUk=; b=d2YuLJxVY7/Z2rVW+s9+69KmW8LToxh6fQ1OfMzIKKaCyFSo/pD6gidN4ZbrkPNqkY ww+Aky8s2OTG0CR/9boyfhmKZd05gLszO+ZVHbFhUlXOs4KXWdWDuUmwc1WukY+6WURt 5pSlNMjf22DJe2vSWaSV/rIu8jcZRJB3HvenxuaCYR1rpiwQ+LwF4e/dAEWj9y0OKbyD YsbhchIrU7fuTDu4sR9bXboRqFVN8+Do83aQGMtQfoypXNk6Hvlz7do3v0ksmkyS5590 PEEOJbqqmYaFZqzw09TXV/GfIuiZ1yVdhlqvjVu7eHe8+nZFyxhAEBE+uFjPv8jC72Xi 4RCA== MIME-Version: 1.0 X-Received: by 10.180.8.197 with SMTP id t5mr5609172wia.27.1360700130322; Tue, 12 Feb 2013 12:15:30 -0800 (PST) Received: by 10.194.119.5 with HTTP; Tue, 12 Feb 2013 12:15:30 -0800 (PST) In-Reply-To: <511A91C5.7010502@FreeBSD.org> References: <51127767.1030007@gmail.com> <5119F6C6.8010802@FreeBSD.org> <2872289.1yXr0e1VeO@melon.malikania.fr> <511A91C5.7010502@FreeBSD.org> Date: Tue, 12 Feb 2013 21:15:30 +0100 Message-ID: Subject: Re: Panic at shutdown From: David Demelier To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 20:15:32 -0000 Okay I will update everything and use GENERIC config, if I get more info I'll tell you :-), Cheers and thanks for your answers 2013/2/12 Andriy Gapon > on 12/02/2013 20:44 David Demelier said the following: > > Le mardi 12 f=C3=A9vrier 2013 10:01:10 Andriy Gapon a =C3=A9crit : > >> on 12/02/2013 09:57 David Demelier said the following: > >>> Yes I have added debugging option in my kernel. I have makeoptions > >>> DEBUG=3D-g in my config. Do I need more ? > >> > >> .symbols? > > > > I don't understand what you are saying, I have > /boot/kernel/kernel.symbols. > > Please tell me what I'm doing wrong. I've just read and done the steps > written > > there : > > > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug- > > gdb.html > > > > So I've run > > > > # cd /usr/obj/usr/src/sys/Melon > > # kgdb kernel.debug /var/crash/vmcore.0 > > > > and that's the only trace I get using bt full : > > > > 229 #define IS_BSP() (PCPU_GET(cpuid) =3D=3D 0) > > (kgdb) bt full > > #0 doadump (textdump=3D) at pcpu.h:229 > > No locals. > > #1 0x0000000000000000 in ?? () > > No symbol table info available. > > I don't know what you are doing wrong, but the above message ("No symbol > table > info available") is wrong. > Perhaps your world (kgdb) and kernel are out of sync, maybe something > else... > > -- > Andriy Gapon > --=20 Demelier David From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 20:42:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BBF3CCE4 for ; Tue, 12 Feb 2013 20:42:03 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews03.kpnxchange.com (cpsmtpb-ews03.kpnxchange.com [213.75.39.6]) by mx1.freebsd.org (Postfix) with ESMTP id 59104FCC for ; Tue, 12 Feb 2013 20:42:02 +0000 (UTC) Received: from cpsps-ews20.kpnxchange.com ([10.94.84.186]) by cpsmtpb-ews03.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Tue, 12 Feb 2013 21:40:43 +0100 Received: from CPSMTPM-TLF102.kpnxchange.com ([195.121.3.5]) by cpsps-ews20.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Tue, 12 Feb 2013 21:40:43 +0100 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF102.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Tue, 12 Feb 2013 21:42:01 +0100 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 39B685D47 for ; Tue, 12 Feb 2013 21:42:01 +0100 (CET) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: Panic at shutdown References: <51127767.1030007@gmail.com> <5119F6C6.8010802@FreeBSD.org> <2872289.1yXr0e1VeO@melon.malikania.fr> Date: Tue, 12 Feb 2013 21:42:01 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Ronald Klop" Message-ID: In-Reply-To: <2872289.1yXr0e1VeO@melon.malikania.fr> User-Agent: Opera Mail/12.14 (FreeBSD) X-OriginalArrivalTime: 12 Feb 2013 20:42:01.0577 (UTC) FILETIME=[68D7BD90:01CE0961] X-RcptDomain: 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, 12 Feb 2013 20:42:03 -0000 On Tue, 12 Feb 2013 19:44:49 +0100, David Demelier = wrote: > Le mardi 12 f=C3=A9vrier 2013 10:01:10 Andriy Gapon a =C3=A9crit : >> on 12/02/2013 09:57 David Demelier said the following: >> > Yes I have added debugging option in my kernel. I have makeoptions >> > DEBUG=3D-g in my config. Do I need more ? >> >> .symbols? > > I don't understand what you are saying, I have = > /boot/kernel/kernel.symbols. > Please tell me what I'm doing wrong. I've just read and done the steps= = > written > there : > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug- > gdb.html > > So I've run > > # cd /usr/obj/usr/src/sys/Melon > # kgdb kernel.debug /var/crash/vmcore.0 Why not something like kgdb /boot/kernel/kernel.symbols = /var/crash/vmcore.0? That looks like what the manual page of kgdb seems to suggest. Regards, Ronald. > > and that's the only trace I get using bt full : > > 229 #define IS_BSP() (PCPU_GET(cpuid) =3D=3D 0) > (kgdb) bt full > #0 doadump (textdump=3D) at pcpu.h:229 > No locals. > #1 0x0000000000000000 in ?? () > No symbol table info available. > > > -- > David Demelier > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.o= rg" From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 21:32:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E2AC264E; Tue, 12 Feb 2013 21:32:25 +0000 (UTC) (envelope-from pj@smo.de) Received: from mx01.ilk.net (mx01.ilk.net [212.86.193.15]) by mx1.freebsd.org (Postfix) with ESMTP id 7D1752B3; Tue, 12 Feb 2013 21:32:25 +0000 (UTC) Received: from smo.de (p5B130316.dip0.t-ipconnect.de [91.19.3.22]) (authenticated bits=0) by mx01.ilk.net (8.13.4/8.13.4/ilk-relay) with ESMTP id r1CLK7JY007134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Feb 2013 22:20:07 +0100 Received: from skjaldbreidur.intern.smo.de (skjaldbreidur.intern.smo.de [192.168.153.212]) by smo.de (8.14.4/8.14.4) with ESMTP id r1CLK6g2020858; Tue, 12 Feb 2013 22:20:06 +0100 (CET) Message-ID: <511AC154.80409@smo.de> Date: Tue, 12 Feb 2013 22:25:24 +0000 From: Philipp-Joachim Ost User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15 MIME-Version: 1.0 To: CeDeROM Subject: Re: 9.1 AMD64 multitasking efficiency low References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-emulation@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, 12 Feb 2013 21:32:26 -0000 CeDeROM wrote: > I have found 9.1 to be far more less responsive than 9.0 and previous > releases on my desktop. I have noted this slow down at 9.1-RC. I have > AMD64 4GB RAM i3 CPU and when I simply run Chromium, VBox with Windows > XP 64bit (1GB allocated) and VBox with Ubuntu 64bit (1GB allocated) my > machine gets unresponsive - it does not even respond to ACPI shutdown, > I need to kill it to get working again :-( I did not happen before. > > I have also noted that VBox 4.2.6 is working far more slower and makes > bigger impact on the whole host performance - sometimes I need to wait > some seconds to get the machine response back, this happens especially > at loading stage :-( I generally do not observe such a behaviour on my machine (AMD FX-6100, 8GB RAM) running 9.1-PRERELEASE amd64 from mid-november '12. The system is ZFS-only and equipped with a single WDC disk. I'm also running VBox 4.2.6 with Fedora Linux (64 bit) as guest; the virtual machine has 1.5GB RAM allocated. There was and is no delay in using the virtual machine. Even under heavy load (load level > 20) the system is interactive, that is, I can watch videos, surf the net, etc. without almost no hiccup. Only if memory is really scarce and I'm copying a large file (~7.5GB) the system becomes kind of slow, e.g. it takes some time to switch between different applications. Up to now, I didn't need to kill my machine to get it working again. HTH, Philipp From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 21:59:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 90F66F49 for ; Tue, 12 Feb 2013 21:59:32 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id D4306670 for ; Tue, 12 Feb 2013 21:59:31 +0000 (UTC) Received: (qmail 23000 invoked by uid 89); 12 Feb 2013 21:59:29 -0000 Received: by simscan 1.4.0 ppid: 22995, pid: 22997, t: 0.0462s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:16670 Received: from unknown (HELO ewzw069.ewadmin.local) (rainer@ultra-secure.de@212.71.117.92) by mail.ultra-secure.de with ESMTPA; 12 Feb 2013 21:59:29 -0000 From: Rainer Duffner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Why does poudriere always rebuild nginx and GraphicsMagick13? Message-Id: Date: Tue, 12 Feb 2013 22:59:28 +0100 To: "freebsd-stable@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 21:59:32 -0000 Hi, poudriere 2.2 here, running on 9.1-amd64 Of the 730-ish ports, whenever I run a build, it always rebuilds the = above two ports. Even if nothing changed. Is there are specific reason for this? I don't really mind nginx, because it builds so quickly - but = GraphicsMagick takes a bit too long. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 12 22:11:15 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 38D972CA for ; Tue, 12 Feb 2013 22:11:15 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by mx1.freebsd.org (Postfix) with ESMTP id B9A7270F for ; Tue, 12 Feb 2013 22:11:14 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id e53so290528eek.26 for ; Tue, 12 Feb 2013 14:11:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=fd3hB1OZ9KDLtTH/ULoM7i4BdD0wIThdxZBje29U56w=; b=I1PvHHWLKEBir+e3OAZojo0+uybDYXtIiCMrZMraQ+v9KHUINbETUWKmBl+sCxGEFJ oMErOhduea8X15/Ugycl1L+KJYRtqsO/iotn8SsWZ9+FcSddY+6tOt/a+ge6lES3hJxW c6cz35F4Dif0ssn9Y8oM7GgaQN6zn62KRLJW2lLCY25SONXEPzulyI20qNQZBRJToXKH 9jIt1nWtTcjJ+fFa1AtWrLx1UVbvgHBVyuGeWnMFS16U9ynBD/1RRg75L3PWduDY1rkI Kt4nEjVgWZEJdiY/QMiiQhThqambhNlckVkHkzt37yjIeAyPaeteYmL01jhJN7xQkSSo JzLA== X-Received: by 10.14.183.67 with SMTP id p43mr66926766eem.10.1360707066843; Tue, 12 Feb 2013 14:11:06 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPS id k7sm67402947een.8.2013.02.12.14.11.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 12 Feb 2013 14:11:05 -0800 (PST) Sender: Baptiste Daroussin Date: Tue, 12 Feb 2013 23:11:03 +0100 From: Baptiste Daroussin To: Rainer Duffner Subject: Re: Why does poudriere always rebuild nginx and GraphicsMagick13? Message-ID: <20130212221103.GG12760@ithaqua.etoilebsd.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xs+9IvWevLaxKUtW" Content-Disposition: inline In-Reply-To: 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: Tue, 12 Feb 2013 22:11:15 -0000 --xs+9IvWevLaxKUtW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 12, 2013 at 10:59:28PM +0100, Rainer Duffner wrote: > Hi, >=20 > poudriere 2.2 here, running on 9.1-amd64 >=20 > Of the 730-ish ports, whenever I run a build, it always rebuilds the abov= e two ports. > Even if nothing changed. >=20 > Is there are specific reason for this? >=20 > I don't really mind nginx, because it builds so quickly - but GraphicsMag= ick takes a bit too long. 2.2 is so old :) please upgrade to at least 2.3.1, lots of things as been fixed since, and s= oon 2.3.2 with lots of other bug fixes. I'm sure 2.3.1 fixes your problems, or at least will explain you why someth= ing is rebuilt (it is now explained during the sanity check) regards, Bapt --xs+9IvWevLaxKUtW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEavfcACgkQ8kTtMUmk6EyunwCeKgcSaxHjDEaAr76GKRLkk/io 5CsAoK7aCGvRGSWqBA7NnUEv8CDDe7Cr =a8M7 -----END PGP SIGNATURE----- --xs+9IvWevLaxKUtW-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 01:34:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CFCF99C8 for ; Wed, 13 Feb 2013 01:34:48 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-da0-f49.google.com (mail-da0-f49.google.com [209.85.210.49]) by mx1.freebsd.org (Postfix) with ESMTP id A3235135 for ; Wed, 13 Feb 2013 01:34:48 +0000 (UTC) Received: by mail-da0-f49.google.com with SMTP id t11so306980daj.36 for ; Tue, 12 Feb 2013 17:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=Yv+WBEk40odReGoYPDlBRh8JQjsztZrXxNByi+Qk+h4=; b=QzNXwtRTO6chrEdhMKpEUDR4fFLltUsNobFjRqy9K4DlhjOKmU2d/V9EC94rjuLnj1 Xk9863kZi09woT4Ed7vwXSkcDPBCWdZ1iY7peGY6pvo01MsYLkNQBGovtf5c3vmolzwQ HTof94nkNFLizffmQozcO6RaQSLwgQmqGn1/6S8n0xB/yc62T5dxHDM/HCvK67siT/XX v71Z82qSIixuSbzLb76C9afpzI6fm0OgoYMpEg79YR8rCrgrhIPzQ7i0rUgIlpzZpS5u uiih9lA2npD5w8Dcu2NBaX/p/qIgI9O38ji8l8i5XwpNpSDZTHlqKAczkoTxMUFhSI2p pfZg== X-Received: by 10.66.81.199 with SMTP id c7mr58051251pay.39.1360719287488; Tue, 12 Feb 2013 17:34:47 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id z10sm79153537pay.7.2013.02.12.17.34.44 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 12 Feb 2013 17:34:46 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 13 Feb 2013 10:34:38 +0900 From: YongHyeon PYUN Date: Wed, 13 Feb 2013 10:34:38 +0900 To: Oliver Fromme Subject: Re: re(4) problems with GA-H77N-WIFI Message-ID: <20130213013438.GA3101@michelle.cdnetworks.com> References: <20130206055322.GA1442@michelle.cdnetworks.com> <201302081927.r18JRtYk017319@grabthar.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201302081927.r18JRtYk017319@grabthar.secnetix.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@FreeBSD.ORG X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 01:34:48 -0000 On Fri, Feb 08, 2013 at 08:27:55PM +0100, Oliver Fromme wrote: > I'm sorry for the late reply. I didn't have much time > this week to investigate this issue. At the moment I > implemented a work-around with an additional switch using > VLANs, but I'd really like to get the second NIC working. > > YongHyeon PYUN wrote: > > On Mon, Feb 04, 2013 at 07:15:51PM +0100, Oliver Fromme wrote: > > > Recently I got a new mainboard for a router, it's a > > > Gigabyte GA-H77N-WIFI with two onboard re(4) NICs. > > > > > > The problem is that re0 works fine and re1 doesn't: > > > It doesn't receive any packets. Tcpdump displays all > > > outgoing packets, but no incoming ones on re1. > > > > Can you see the packets sent from re1 on other box? > > No. I can only see them locally in tcpdump, but they never > hit the wire. > > > If not, it probably indicates GMAC is in weird state which in turn > > indicates initialization was not complete for the controller. > > > > > Ifconfig shows the link correctly (100 or 1000 Mbit, > > > depending on where I plug the cable in). > > > I also swapped cables just to be sure, but it made no > > > difference. > > > > If you cold-boot the box with UTP cable plugged in to re1 does it > > make any difference? > > No, it doesn't. > > > > I'm running a recent stable/9 (about 14 days old). > > > What's the best way to debug this problem? At the > > > > I would check whether GMAC is active when driver detects a valid > > link. Add a code like the following to re_miibus_statchg() to get > > the status of RL_COMMAND register. You would get the status > > whenever a link is established with link partner. > > re0: CMD 0x0c > re0: link state changed to UP > re0: link state changed to DOWN > re1: link state changed to UP > re1: link state changed to DOWN > re1: CMD 0x0c > re1: link state changed to UP > re0: CMD 0x0c > re0: link state changed to UP > re1: link state changed to DOWN > > I always seem to get 0x0c for both re0 and re1. Hmm, it seems GMAC is in sane state. Would you show me the output of "devinfo -rv | grep rgephy"? To rule out hardware issues, could you also try other OS like Linux? > > Best regards > Oliver From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 01:50:47 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B1690CE7; Wed, 13 Feb 2013 01:50:47 +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 436431D7; Wed, 13 Feb 2013 01:50:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAEnwGlGDaFvO/2dsb2JhbAA6CoZOujlzgh8BAQEEAQEBIAQnIAsbDgoCAg0ZAikBCSYGCAcEAQgUBIdxDK1EgkCPd4EjjBwKgymBEwOIZosLgjOBHY82gyRPgQU1 X-IronPort-AV: E=Sophos;i="4.84,654,1355115600"; d="scan'208";a="13758444" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 12 Feb 2013 20:50:39 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 77686B3F4A; Tue, 12 Feb 2013 20:50:39 -0500 (EST) Date: Tue, 12 Feb 2013 20:50:39 -0500 (EST) From: Rick Macklem To: Marc Fournier Message-ID: <339364797.2960794.1360720239431.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <61DAA500-EB20-4861-AA7F-402FF1047B81@hub.org> Subject: Re: 9-STABLE -> NFS -> NetAPP: 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 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Kostik Belousov , freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 01:50:47 -0000 Marc Fournier wrote: > Just reset server, so any further details will have to be 'next time' > =E2=80=A6 but, just did a csup and am rebuilding =E2=80=A6 the following = three files > were modified since last build: >=20 > grep nfs /tmp/output > Edit src/sys/fs/nfs/nfs_commonsubs.c > Edit src/sys/fs/nfsclient/nfs_clrpcops.c > Edit src/sys/fs/nfsserver/nfs_nfsdserv.c >=20 >=20 > On 2013-02-10, at 4:56 PM, Marc Fournier wrote: >=20 > > > > On 2013-02-10, at 4:31 PM, Rick Macklem > > wrote: > > > >> Marc Fournier wrote: > >>> Hi John =E2=80=A6 > >>> > >>> Does this help? > >>> > >>> root@io:~ # ps auxl | grep du > >>> root 1054 0.0 0.1 16176 6600 ?? D 3:15AM 0:05.38 du -skx /vm/2799 > >>> 0 > >>> 81426 0 20 0 newnfs > >>> root 12353 0.0 0.1 16176 5104 ?? D Sat03AM 0:05.41 du -skx > >>> /vm/2799 0 > >>> 91597 0 20 0 newnfs > >>> root 64529 0.0 0.1 16176 5164 ?? D Fri03AM 0:05.40 du -skx > >>> /vm/2799 0 > >>> 43227 0 20 0 newnfs > >>> root 12855 0.0 0.0 16308 1988 0 S+ 5:26AM 0:00.00 grep du 0 12847 > >>> 0 20 > >>> 0 piperd > >> It is probably too late, but all the lines (without the | grep du) > >> would be > >> more useful. I also include the "H" flag, so it lists threads as > >> well as > >> processes. The above just says the "du" command is waiting for a > >> vnode lock. > >> The interesting process/thread is the one that is holding a vnode > >> lock > >> while waiting for something else. > > > > As requested, 'ps auxlH' attached =E2=80=A6 > > > > > > > > Well, I took a look at the ps output and I didn't see anything that would identify what the hang is. There are a lot of processes sleeping on "newnfs= " (waiting for a vnode lock) and many sleeping on "vofflock" (waiting for the f_offset lock). Unfortunately, I can't spot any process/thread that is blocked on something else, where it would seem likely to be holding either an nfs vnode lock or f_offset lock that isn't one of these. There were changes about 5 months ago which it appears fixed a deadlock rac= e between vnode locks and offset locks for paging (r236321 and friends). I am wondering if there could be other similar races, possibly specific to paging in over NFS? (I can't see any case where there is a LOR, so I can't think of what it might be?) If you just want the hangs to go away, I'd suggest moving the executable is /usr/local/sbin (httpd maybe) to a local file system on the server, since it does seem to be related to paging this executable in over NFS. rick ps: I've added kib@ to the cc, in case he is aware of other related races? > >> > >> Are you still getting the: > >> nfs_getpages: error 13 > >> vm_fault: pager read error, pid 11355 (https) > > > > Fairly quiet: > > > > > > > > And that is it since last reboot ~20 days ago =E2=80=A6 > > > >> > >> messages logged? > >> > >> With John's recent patch, the error# would no longer be 13 if it > >> was > >> caused by the "intr" flag resulting in a Read RPC terminating with > >> EINTR. > >> If you are still getting the above with "error 13", it suggests > >> that > >> the server is replying EACCES for the Read RPC. > >> I suggested before that you check to make sure that the executable > >> had > >> read access for everyone one the file server. Since I didn't hear > >> back, > >> I'll assume this is the case. > > > > Don't understand this question =E2=80=A6 I have 34 VPSs running off of = this > > server right now =E2=80=A6 that 'du process' runs against each of those= VPSs > > every night, and this problem started happening on Friday night's > > run =E2=80=A6 ~18 days into uptime =E2=80=A6 so the same process has ru= n repeatedly, > > with no issues, 18 times before it hung on Friday =E2=80=A6 also, the h= ang, > > once 'triggered', only seems to recur against the same directory =E2=80= =A6 > > the same directory doesn't necessarily trigger it, but once it > > starts, it appears to do it for the same directory =E2=80=A6 I'm not su= re if > > I've ever seem it happening to two different directories at the same > > time =E2=80=A6 > > > > Also, please note that the du command is run from the physical > > server, as root =E2=80=A6 > > > >> rick > >> ps: If it is still up and hasn't been rebooted, you could: > >> sysctl debug.kdb.break_to_debugger=3D1 > >> - then type at the console and do the following > >> from the debugger > >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook= /kerneldebug-deadlocks.html > >> How well this work depends on what options your kernel was built > >> with. > > > > My remote console on that one doesn't work very well =E2=80=A6 I can vi= ew, > > but I can't type =E2=80=A6 > > > > >=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" From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 03:08:43 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6E24CF84; Wed, 13 Feb 2013 03:08:43 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [92.53.116.57]) by mx1.freebsd.org (Postfix) with ESMTP id 211EA6F3; Wed, 13 Feb 2013 03:08:42 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1U5RzE-0008Gf-94; Wed, 13 Feb 2013 06:22:16 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id C41A8B84D; Wed, 13 Feb 2013 06:22:15 +0400 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id B18A8D9; Wed, 13 Feb 2013 06:22:15 +0400 (MSK) Date: Wed, 13 Feb 2013 06:22:15 +0400 From: Dmitry Marakasov To: Kimmo Paasiala Subject: Re: CLANG and -fstack-protector Message-ID: <20130213022215.GK99263@hades.panopticon> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD current , 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, 13 Feb 2013 03:08:43 -0000 * Kimmo Paasiala (kpaasial@gmail.com) wrote: > Does the -fstack-protector option work on CLANG 3.1 and 3.2? > > There is thread on FreeBSD forums about the stack protector and ports > and I'm wondering if it's possible to use the -fstack-protector option > with CLANG. > > http://forums.freebsd.org/showthread.php?t=36927 You might be interested in this patch: https://github.com/AMDmi3/freebsd-ports-mk/compare/master...stack-protector afaik, in prior discussion some years ago an issue was mentioned that some ports don't build with stack-protector, so I suggested to introduce STACK_PROTECTOR_SAFE/_UNSAFE knobs similar to what we have for MAKE_JOBS_SAFE_/_UNSAFE (we might actually only need STACK_PROTECTOR_UNSAFE, as unlike MAKE_JOBS, build errors caused by enabling stack protector are not transient, so we can have an exp-run to just mark all uncompatible ports and consider all others compatible). If there's interest in this, I can refresh the patch and submit it. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 03:23:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 59EB395C for ; Wed, 13 Feb 2013 03:23:09 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 35FB67C0 for ; Wed, 13 Feb 2013 03:23:09 +0000 (UTC) Received: by mail-da0-f44.google.com with SMTP id z20so337197dae.31 for ; Tue, 12 Feb 2013 19:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=+mpSwHPujS2b0jIA/a6yCfTKu3GZh0AK1HNMgyuYXd4=; b=Xiw38itGwavsvbBxvw2Q0qteHChyQGJ/sm+WPW2mbLT4MpUqijXkPj6arZ9KBFW4iT 5H0AYxf2k4K+D66kYUnb6wUEYeIHQxjDLOPATs+AOndxnCrLhao17cQFlNTEy+aydBLy e1irxWqufvEpy/qhC2gDjMXN+vG1yGiLyPsdg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=+mpSwHPujS2b0jIA/a6yCfTKu3GZh0AK1HNMgyuYXd4=; b=Wify5RrRITlXPZeANgppEv7lAEz3t5PE2rI9X89KVr9KHhlA2foDvrTR8u1fM4ASsD /mzI/CuYq97+eP3naLYYv1lg/a81ex0Ij0Bp1E9h5agSgljUfi71DD/UNkDB1HxuSAcG uqjT0+2HlapEvyhtLa/p6Nzb4sfbOXzP5Uj8Lfj6RdmUVHkzunrgN9hj4uZkUzIGCISC Hza01xR9TEID/5Q/rpdCCTY5QgTamtba0Y2RpBZgdhnVKJ2txOEshoUVhLTlIzXY2iFE FSHNwvBDMx8vfFjKPwhc0dXIPvFvgxjf1f3DQ8wfBLTK2BPyBbQt1DokpOvKjUhGrVZR iGcg== X-Received: by 10.66.72.97 with SMTP id c1mr58947096pav.48.1360725783529; Tue, 12 Feb 2013 19:23:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.148.10 with HTTP; Tue, 12 Feb 2013 19:22:33 -0800 (PST) In-Reply-To: <20130213022215.GK99263@hades.panopticon> References: <20130213022215.GK99263@hades.panopticon> From: Eitan Adler Date: Tue, 12 Feb 2013 22:22:33 -0500 Message-ID: Subject: Re: CLANG and -fstack-protector To: Dmitry Marakasov Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkadOzcY8mXrxY2SL8GadthYbXNvSwWXaZK2Q+jogc2jZxm/5L9KvMW//XLFuCrtJY+Io08 Cc: Kimmo Paasiala , FreeBSD current , 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, 13 Feb 2013 03:23:09 -0000 On 12 February 2013 21:22, Dmitry Marakasov wrote: > If there's interest in this, I can refresh the patch and submit it. Yes. Please do! -- Eitan Adler From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 05:09:06 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B192D89F; Wed, 13 Feb 2013 05:09:06 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [199.192.164.235]) by mx1.freebsd.org (Postfix) with ESMTP id 8882EAB1; Wed, 13 Feb 2013 05:09:03 +0000 (UTC) Received: from glorfindel.gritton.org (c-174-52-130-157.hsd1.ut.comcast.net [174.52.130.157]) (authenticated bits=0) by m2.gritton.org (8.14.5/8.14.5) with ESMTP id r1D591ok070158; Tue, 12 Feb 2013 22:09:02 -0700 (MST) (envelope-from jamie@FreeBSD.org) Message-ID: <511B1FED.7000500@FreeBSD.org> Date: Tue, 12 Feb 2013 22:09:01 -0700 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20120129 Thunderbird/3.1.16 MIME-Version: 1.0 To: freebsd-jail@FreeBSD.org Subject: Re: problem stoping jails with jail(8), jail.conf and mount.fstab References: <511A55F9.4080205@omnilan.de> In-Reply-To: <511A55F9.4080205@omnilan.de> Content-Type: text/plain; charset=ISO-8859-15; 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: Wed, 13 Feb 2013 05:09:06 -0000 On 02/12/13 07:47, Harald Schmalzbauer wrote: > Hello, > > on 9.1-R, I highly appreciate the new jail(8) and jail.conf > capabilities. Thanks for that extension! > > But I have one problem: If I want to stop a jail with 'jaill -r > jailname', I get "umount: unmount of /.jail.jailname failed: Device busy" > > It seems to me that the order of fstab.jailname entries are not reverted > by jail(8) when shutting down/umounting. > My C skills don't allow me to verify/fix that in usr.sbin/jail/command.c > > Can anybody help please? > > Thanks, > > -Harry Yes, that's a serious drawback. I'll work something up for that. - Jamie From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 07:03:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 56CD428A for ; Wed, 13 Feb 2013 07:03:17 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id D4791E60 for ; Wed, 13 Feb 2013 07:03:16 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by kabab.cs.huji.ac.il with esmtp id 1U5WN0-000OQf-4v; Wed, 13 Feb 2013 09:03:06 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Luigi Rizzo Subject: Re: ix? / Intel(R) PRO/10GbE In-reply-to: References: Comments: In-reply-to Luigi Rizzo message dated "Tue, 12 Feb 2013 07:27:50 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Feb 2013 09:03:06 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 07:03:17 -0000 thanks Luigi, the 'confusion' could have been avoided if at least in the dmesg, the fuller name was used, and yes, I hate apple/linux just calling then eth0, eth1 :-) danny > ixgbe is the _driver name_, ix is the _interface name_ you > see in ifconfig. The latter is usually shorter. > > Also there are overlaps, e.g. the lem, em and igb drivers > all map to "em" as interface name. > > cheers > luigi > > > On Tue, Feb 12, 2013 at 7:21 AM, Daniel Braniss wrote: > > > I finally got a 10G card that is recognized by FreeBSD (9.1-stable): > > ... > > ix0: port > > 0xecc0-0xecdf mem 0xd9e80000-0xd9efffff,0xd9ff8000-0xd9ffbfff irq 40 at > > device > > 0.0 on pci4 > > ix0: Using MSIX interrupts with 9 vectors > > ix0: RX Descriptors exceed system mbuf max, using default instead! > > ix0: Ethernet address: 90:e2:ba:29:c0:54 > > ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 > > ... > > but it apperas as ix0/ix1, manuals only mention ixgb/e, > > and ifconfig: > > > > ix0: flags=8802 metric 0 mtu 1500 > > > > options=401bb > UM,TSO4,VLAN_HWTSO> > > ether 90:e2:ba:29:c0:54 > > nd6 options=21 > > media: Ethernet autoselect > > status: no carrier > > ix1: flags=8802 metric 0 mtu 1500 > > > > options=401bb > UM,TSO4,VLAN_HWTSO> > > ether 90:e2:ba:29:c0:55 > > nd6 options=21 > > media: Ethernet autoselect > > status: no carrier > > > > and pciconf: > > ix0@pci0:4:0:0: class=0x020000 card=0x7a118086 chip=0x10fb8086 rev=0x01 > > hdr=0x00 > > vendor = 'Intel Corporation' > > device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' > > class = network > > subclass = ethernet > > > > Secondly how is this fixable: > > RX Descriptors exceed system mbuf max, using default instead! > > > > thanks, > > danny > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > > --e89a8f2346bd28ba3c04d588ab1a > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > >
ixgbe is the _driver = > name_, ix is the _interface name_ you
monospace">see in ifconfig. The latter is usually shorter.
style> >
Also there are o= > verlaps, e.g. the lem, em and igb drivers
=3D"courier new, monospace">all map to "em" as interface name. ont>
>

e>cheers
face=3D"courier new,monospace">luigi
extra"> >

On Tue, Feb 12, 2013 at 7:21 AM, Daniel = > Braniss < =3D"_blank">danny@cs.huji.ac.il> wrote:
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= > ing-left:1ex"> > I finally got a 10G card that is recognized by FreeBSD (9.1-stable):
> ...
> ix0: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.8>= > port
> 0xecc0-0xecdf mem 0xd9e80000-0xd9efffff,0xd9ff8000-0xd9ffbfff irq 40 at dev= > ice
> 0.0 on pci4
> ix0: Using MSIX interrupts with 9 vectors
> ix0: RX Descriptors exceed system mbuf max, using default instead!
> ix0: Ethernet address: 90:e2:ba:29:c0:54
> ix0: PCI Express Bus: Speed 5.0Gb/s Width x8
> ...
> but it apperas as ix0/ix1, manuals only mention ixgb/e,
> and ifconfig:
>
> ix0: flags=3D8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
> =A0 =A0 =A0 =A0 options=3D401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JU= > MBO_MTU,VLAN_HWCS
> UM,TSO4,VLAN_HWTSO>
> =A0 =A0 =A0 =A0 ether 90:e2:ba:29:c0:54
> =A0 =A0 =A0 =A0 nd6 options=3D21<PERFORMNUD,AUTO_LINKLOCAL>
> =A0 =A0 =A0 =A0 media: Ethernet autoselect
> =A0 =A0 =A0 =A0 status: no carrier
> ix1: flags=3D8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
> =A0 =A0 =A0 =A0 options=3D401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JU= > MBO_MTU,VLAN_HWCS
> UM,TSO4,VLAN_HWTSO>
> =A0 =A0 =A0 =A0 ether 90:e2:ba:29:c0:55
> =A0 =A0 =A0 =A0 nd6 options=3D21<PERFORMNUD,AUTO_LINKLOCAL>
> =A0 =A0 =A0 =A0 media: Ethernet autoselect
> =A0 =A0 =A0 =A0 status: no carrier
>
> and pciconf:
> ix0@pci0:4:0:0: class=3D0x020000 card=3D0x7a118086 chip=3D0x10fb8086 rev=3D= > 0x01
> hdr=3D0x00
> =A0 =A0 vendor =A0 =A0 =3D 'Intel Corporation'
> =A0 =A0 device =A0 =A0 =3D '82599EB 10-Gigabit SFI/SFP+ Network Connect= > ion'
> =A0 =A0 class =A0 =A0 =A0=3D network
> =A0 =A0 subclass =A0 =3D ethernet
>
> Secondly how is this fixable:
> =A0 =A0 =A0 =A0 RX Descriptors exceed system mbuf max, using default instea= > d!
>
> thanks,
> =A0 =A0 =A0 =A0 danny
>
> _______________________________________________
> freebsd-stable@freebsd.org > mailing list
> =3D"_blank">http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to " ubscribe@freebsd.org">freebsd-stable-unsubscribe@freebsd.org"
>



--
=3D"'courier new', monospace">-------------------------------------= > ----+-------------------------------
=A0Prof. Luigi RIZZO, ailto:rizzo@iet.unipi.it" target=3D"_blank">rizzo@iet.unipi.it =A0. Dip= > . di Ing. dell'Informazione
> =A0http://ww= > w.iet.unipi.it/~luigi/ =A0 =A0 =A0 =A0. Universita` di Pisa
=A0TEL = > =A0 =A0 =A0+39-050-2211611 =A0 =A0 =A0 =A0 =A0 =A0 =A0 . via Diotisalvi 2 r> =A0Mobile =A0 +39-338-6809875 =A0 =A0 =A0 =A0 =A0 =A0 =A0 . 56122 PISA (= > Italy)
> -----------------------------------------+------------------------------- font>
>
> > --e89a8f2346bd28ba3c04d588ab1a-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 07:18:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2E3965B5 for ; Wed, 13 Feb 2013 07:18:25 +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 A3767F08 for ; Wed, 13 Feb 2013 07:18:24 +0000 (UTC) Received: from ppp247-71.static.internode.on.net (HELO leader.local) ([203.122.247.71]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Feb 2013 17:48:23 +1030 Message-ID: <511B3E3D.5010005@ShaneWare.Biz> Date: Wed, 13 Feb 2013 17:48:21 +1030 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dmitry Marakasov Subject: Re: CLANG and -fstack-protector References: <20130213022215.GK99263@hades.panopticon> In-Reply-To: <20130213022215.GK99263@hades.panopticon> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kimmo Paasiala , 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, 13 Feb 2013 07:18:25 -0000 On 13/02/2013 12:52, Dmitry Marakasov wrote: > afaik, in prior discussion some years ago an issue was mentioned that > some ports don't build with stack-protector, so I suggested to introduce > STACK_PROTECTOR_SAFE/_UNSAFE knobs similar to what we have for > MAKE_JOBS_SAFE_/_UNSAFE (we might actually only need > STACK_PROTECTOR_UNSAFE, as unlike MAKE_JOBS, build errors caused by > enabling stack protector are not transient, so we can have an exp-run > to just mark all uncompatible ports and consider all others compatible). > > If there's interest in this, I can refresh the patch and submit it. > I think it sounds like a good idea - I'd go with only specify unsafe when needed. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 07:29:09 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 310F2720 for ; Wed, 13 Feb 2013 07:29:09 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id D1F35F4F for ; Wed, 13 Feb 2013 07:29:08 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by kabab.cs.huji.ac.il with esmtp id 1U5WmA-000Or3-TL; Wed, 13 Feb 2013 09:29:07 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: "Teske, Devin" Subject: Re: ix? / Intel(R) PRO/10GbE In-reply-to: <13CA24D6AB415D428143D44749F57D7201EA7586@ltcfiswmsgmb21> References: <13CA24D6AB415D428143D44749F57D7201EA7586@ltcfiswmsgmb21> Comments: In-reply-to "Teske, Devin" message dated "Tue, 12 Feb 2013 15:30:44 +0000." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Feb 2013 09:29:06 +0200 From: Daniel Braniss Message-ID: Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 07:29:09 -0000 > On Tue, 12 Feb 2013, Daniel Braniss wrote: >=20 > > I finally got a 10G card that is recognized by FreeBSD (9.1-stable): > > ... > > ix0: = port > > 0xecc0-0xecdf mem 0xd9e80000-0xd9efffff,0xd9ff8000-0xd9ffbfff irq 40 = at d=3Device > > 0.0 on pci4 > > ix0: Using MSIX interrupts with 9 vectors > > ix0: RX Descriptors exceed system mbuf max, using default instead=21 > > From reading sys/dev/ixgbe/README: >=20 > echo =22kern.ipc.nmbclusters=3D262144=22 >> /etc/sysctl.conf > echo =22kern.ipc.nmbjumbop=3D262144=22 >> /etc/sysctl.conf > reboot > -- > Devin > Hi Devin, keep forgetting, 'may the source be with you' :-) but this only works if the driver is loaded after the sysctl is executed=21 it's better to put it in /boot/loader.conf thanks, danny From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 07:42:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E6A9CA48 for ; Wed, 13 Feb 2013 07:42:19 +0000 (UTC) (envelope-from c47g@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by mx1.freebsd.org (Postfix) with ESMTP id 5DE98FC1 for ; Wed, 13 Feb 2013 07:42:19 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.30]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M3xZE-1UvqLw0FEY-00rbzf for ; Wed, 13 Feb 2013 08:42:18 +0100 Received: (qmail invoked by alias); 13 Feb 2013 07:42:17 -0000 Received: from cm56-168-232.liwest.at (EHLO bones.gusis.at) [86.56.168.232] by mail.gmx.net (mp030) with SMTP; 13 Feb 2013 08:42:17 +0100 X-Authenticated: #9978462 X-Provags-ID: V01U2FsdGVkX18TtuAhTHwTptn/u+kl4Uk44id5y7DQd2Bhu7KICY ei5MCiBtAa8MhV From: Christian Gusenbauer To: CeDeROM Subject: Re: 9.1 AMD64 multitasking efficiency low Date: Wed, 13 Feb 2013 08:44:44 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201302130844.45388.c47g@gmx.at> X-Y-GMX-Trusted: 0 Cc: Bernhard =?iso-8859-1?q?Fr=F6hlich?= , freebsd-emulation@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, 13 Feb 2013 07:42:20 -0000 On Tuesday 12 February 2013 14:24:24 CeDeROM wrote: > On Tue, Feb 12, 2013 at 2:17 PM, CeDeROM wrote: > > On Tue, Feb 12, 2013 at 2:04 PM, Christian Gusenbauer wrote: > >> Maybe it's hardware related? I experience the same slowness as you do as > >> soon as I copy more than a few MB of data *on the same drive*. (...) > > > > Hello Christian :-) Thank you for your feedback! :-) There was no > > problem today to copy from internal ufs2 to external ufs2, but I have > > tried to copy back from external (ufs2) to internal (ufs2) and guess > > what - I got the terrible slowdown!!! Just when I hit Ctrl+C things > > get back to normal right away.. so the problem is with writing to the > > WDC SATA drive... > > I also noticed that issue on a far more powerful machine and the WDC > 2TB drive. At first I thought the drive was broken, then I switched > from ext2 to ufs2 that improved efficiency to an acceptable level, but > still it does not look as it should, maybe something wrong with the > SATA(2) driver or the WDC drives :-) Glad to hear I am not alone, > thanks!! :-) Hi Tomek! Yeah, we're not alone anymore :-)! My external device is connected to a JMicron JMB363 AHCI SATA controller whereas my internal drive is connected to an Intel ICH8 AHCI SATA controller. As soon as I have some time I'll connect my new external drive to the Intel controller and have a look if that works or not. Maybe it's the combination Intel SATA controller and WDC drives? Ciao, Christian. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 07:55:59 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F11B5DC8 for ; Wed, 13 Feb 2013 07:55:59 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id B5DCFFC for ; Wed, 13 Feb 2013 07:55:59 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id r1D7thmD019386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Feb 2013 01:55:50 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.02.0309.002; Wed, 13 Feb 2013 01:55:48 -0600 From: "Teske, Devin" To: Daniel Braniss Subject: RE: ix? / Intel(R) PRO/10GbE Thread-Topic: ix? / Intel(R) PRO/10GbE Thread-Index: AQHOCTS51RZcgQACiESvcPSCI1tHdZh2WHTBgAFxUwD//6EmDg== Date: Wed, 13 Feb 2013 07:55:47 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201EA7B3E@ltcfiswmsgmb21> References: <13CA24D6AB415D428143D44749F57D7201EA7586@ltcfiswmsgmb21>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-02-13_03:2013-02-12,2013-02-13,1970-01-01 signatures=0 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 07:56:00 -0000 On Tue, 12 Feb 2013, Daniel Braniss wrote: > > On Tue, 12 Feb 2013, Daniel Braniss wrote: > > > > > I finally got a 10G card that is recognized by FreeBSD (9.1-stable): > > > ... > > > ix0: = port > > > 0xecc0-0xecdf mem 0xd9e80000-0xd9efffff,0xd9ff8000-0xd9ffbfff irq 40 = at d=3Device > > > 0.0 on pci4 > > > ix0: Using MSIX interrupts with 9 vectors > > > ix0: RX Descriptors exceed system mbuf max, using default instead! > > > > From reading sys/dev/ixgbe/README: > > > > echo "kern.ipc.nmbclusters=3D262144" >> /etc/sysctl.conf > > echo "kern.ipc.nmbjumbop=3D262144" >> /etc/sysctl.conf > > reboot >=20 > but this only works if the driver is loaded after > the sysctl is executed! > it's better to put it in /boot/loader.conf Not necessarily, it depends when the driver grabs the mbufs. In the case of= the igb/ixgb/ixgbe drivers, this happens when the interface is brought up = (not when the driver is loaded, nor when the driver probes/attaches a PHY).= In other words, you don't have to worry about mbuf exhaustion until you sa= y "ifconfig ix0 up" (in the case of ixgbe, bringing up even a single interf= ace is enough through the default mbufs and require more). Since sysctl.conf is processed before the network is brought up, putting th= e parameters in sysctl.conf will be perfectly suitable for most needs (unle= ss for some strange reason you need to "up" an interface before sysctl.conf= is processed). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 08:02:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DFD43F3D for ; Wed, 13 Feb 2013 08:02:24 +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 5FFB4130 for ; Wed, 13 Feb 2013 08:02:24 +0000 (UTC) Received: from ppp247-71.static.internode.on.net (HELO leader.local) ([203.122.247.71]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Feb 2013 18:32:23 +1030 Message-ID: <511B488D.9080809@ShaneWare.Biz> Date: Wed, 13 Feb 2013 18:32:21 +1030 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Philipp-Joachim Ost Subject: Re: 9.1 AMD64 multitasking efficiency low References: <511AC154.80409@smo.de> In-Reply-To: <511AC154.80409@smo.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, CeDeROM X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Feb 2013 08:02:24 -0000 I have two WD's a 1TB and a 2TB. Upgraded to 9.1 three days ago and don't think it is any worse than 9.0. I find things slow down if two things are trying to access the drive at the same time and when I do get some swapping it gets unbearable. One thing that always annoyed me was the security scans that start early morning, they make any tinderbox builds I leave running grind to a halt. They also run shortly after startup - and they show little cpu usage. Disable them by adding to /etc/periodic.conf daily_status_security_chksetuid_enable="NO" daily_status_security_neggrpperm_enable="NO" I'm sure the first one is a long scan but haven't verified the second. I think I recall the aio module made a difference for me. I believe kldload aio will make it active straight away - if not aio_load="YES" in /etc/loader.conf to load at boot I have a desktop machine - ASUS P8H61-M/LE corei5 8GB 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: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich4 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad8 From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 10:06:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 93F2BDCA; Wed, 13 Feb 2013 10:06:23 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by mx1.freebsd.org (Postfix) with ESMTP id 3723E7DC; Wed, 13 Feb 2013 10:06:22 +0000 (UTC) Received: by mail-qe0-f53.google.com with SMTP id 1so443557qee.26 for ; Wed, 13 Feb 2013 02:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FxJrMdw3+ZsG8TOFfKUIuCuX7ONmKdcow5PTklo1Nq8=; b=h5P/f3ZIFeGYhpi7jbm+I3ekgvx6OSYURWA8Ei2PO9NkNFfKnzlJfQ2gqOKE7ifMHT 5Q7Zz7wWFd54mNGp60CukriNgei7mMPN6LySkmc+23JIpeFDCDUBaK7OWTLXEfo7YjAR 82UIjaKG+whsKLNfd86M5wzExscwleCss0Q9s0qU7R7WOrVYIMYv4IwoDgQ3BT358cl2 DhnEDfb4B0bUDJZFPsp7PX68+iTBM1cOgk1A0PhOVw6ZX/kCGBnaQn+MwUglmX7wC7jO ANdDG9Neam1zrMQ+9jdiob6YLADDpj0FOCgR8ysEyfqkMqIFB85AxSw0828D6WWYhS6j N0MQ== MIME-Version: 1.0 X-Received: by 10.49.105.73 with SMTP id gk9mr9564388qeb.40.1360749491737; Wed, 13 Feb 2013 01:58:11 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Wed, 13 Feb 2013 01:58:11 -0800 (PST) In-Reply-To: <201302130844.45388.c47g@gmx.at> References: <201302130844.45388.c47g@gmx.at> Date: Wed, 13 Feb 2013 10:58:11 +0100 X-Google-Sender-Auth: NNXpLaEARPm0Be7x98yIf3cA4ns Message-ID: Subject: Re: 9.1 AMD64 multitasking efficiency low From: CeDeROM To: Christian Gusenbauer Content-Type: text/plain; charset=UTF-8 Cc: =?UTF-8?Q?Bernhard_Fr=C3=B6hlich?= , freebsd-emulation@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, 13 Feb 2013 10:06:23 -0000 I am not sure if this is the case of external drive, it only helped us to figure out that problem is with writing to ICH SATA - WDC configuration. It was also slow in 9.0 I guess, this is why I have switched from Ext2 to UFS2 to get some speedup, so things are lets say acceptable for the Atari fan =) Maybe the configuration of buffering/cache is wrong and can be fixed easily with camcontrol but I have no experience with that, I have started poking a bit but it coredumped, and I am not really keen to misconfigura that drive and lose all data, so I prefer to wait for someone with experience to come into discussion :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 10:24:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C6104801; Wed, 13 Feb 2013 10:24:16 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by mx1.freebsd.org (Postfix) with ESMTP id 678FA909; Wed, 13 Feb 2013 10:24:16 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id cr7so2062180qab.15 for ; Wed, 13 Feb 2013 02:24:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TTfDorqNQ1DM3AAfoiDUIs5WBM80cS+ciuwU1KjUfxA=; b=khnLcB3WfKQKqaghRYEjFNQp364a++sYQMMFzKtvYIWMqiLQM2NYmWodU0/k7Ze9A4 T5jBFkxp87rIGzNvx3+eABEiTxZdN06F8RHju/HpnJyRVnB7Pe9AfGgx76EDLWe6+M9R HlCBgeS2UgkuNSNVjraW+jDc5qKdnrTrIFls7wV5WYYjNwjotPvAZL7m9zOshJ8K+nJU UGuW6LxXx7D7Jx36S1WSmqsO0yzQHIHnpFt3MTdzGSdgmAy7x59aOAQ16EOiZO/wJiCF 3UkdgPxjwif6PnCTCEwUbkMSGCrXKUFq0ZEaV5/hECbD5ng+vxA+CTqnKSHCYgdKaZAk Kl4A== MIME-Version: 1.0 X-Received: by 10.49.105.73 with SMTP id gk9mr9593707qeb.40.1360751050521; Wed, 13 Feb 2013 02:24:10 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Wed, 13 Feb 2013 02:24:10 -0800 (PST) In-Reply-To: References: <201302130844.45388.c47g@gmx.at> Date: Wed, 13 Feb 2013 11:24:10 +0100 X-Google-Sender-Auth: K9idk6CCDJvrgmfp6Cp1WnENUxA Message-ID: Subject: Re: 9.1 AMD64 multitasking efficiency low From: CeDeROM To: Christian Gusenbauer Content-Type: text/plain; charset=UTF-8 Cc: =?UTF-8?Q?Bernhard_Fr=C3=B6hlich?= , freebsd-emulation@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, 13 Feb 2013 10:24:16 -0000 On Wed, Feb 13, 2013 at 10:58 AM, CeDeROM wrote: > I am not sure if this is the case of external drive, it only helped us > to figure out that problem is with writing to ICH SATA - WDC > configuration. Sorry, this is not exactly true - this happens on both Intel i5 equipment and AMD PhenomII x6 equipment. Both use SATA, both use WDC drives. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 10:25:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E368AA37; Wed, 13 Feb 2013 10:25:53 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from zoom.lafn.org (zoom.lafn.org [108.92.93.123]) by mx1.freebsd.org (Postfix) with ESMTP id C1188938; Wed, 13 Feb 2013 10:25:53 +0000 (UTC) Received: from [10.0.1.2] (static-71-177-216-148.lsanca.fios.verizon.net [71.177.216.148]) (authenticated bits=0) by zoom.lafn.org (8.14.3/8.14.2) with ESMTP id r1DAPkUQ045351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Feb 2013 02:25:47 -0800 (PST) (envelope-from bc979@lafn.org) From: Doug Hardie Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Unusual TCP/IP Packet Size Date: Wed, 13 Feb 2013 02:25:46 -0800 Message-Id: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org> To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.97 at zoom.lafn.org X-Virus-Status: Clean Cc: yongari@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, 13 Feb 2013 10:25:54 -0000 Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has the = following interface: msk0: flags=3D8843 metric 0 mtu = 1500 = options=3Dc011b ether 00:11:2f:2a:c7:03 inet 10.0.1.199 netmask 0xffffff00 broadcast 10.0.1.255 inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1=20 nd6 options=3D29 media: Ethernet autoselect (100baseTX = ) status: active It sent the following packet: (data content abbreviated) 02:14:42.081617 IP 10.0.1.199.443 > 10.0.1.2.61258: Flags [P.], seq = 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr = 920110183], length 3946 0x0000: 4500 0f9e ea89 4000 4006 2a08 0a00 01c7 = E.....@.@.*..... 0x0010: 0a00 0102 01bb ef4a ece1 680b ae37 1bbc = .......J..h..7.. 0x0020: 8018 0410 3407 0000 0101 080a 17f3 8ff8 ....4...=85=85. The indicated packet length is 3946 and the load of data shown is that = size. The MTU on both interfaces is 1500. The receiving system = received 3 packets. There is a router and switch between them. One of = them fragmented that packet. This is part of a SSL/TLS exchange and one = side or the other is hanging on this and just dropping the connection. = I suspect the packet size is the issue. ssldump complains about the = packet too and stops monitoring. Could this possibly be related to the = hardware checksums? From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 10:30:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8411EC2F; Wed, 13 Feb 2013 10:30:03 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 2E4B1974; Wed, 13 Feb 2013 10:30:02 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r1DATwiP084062; Wed, 13 Feb 2013 17:29:59 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <511B6B21.5030606@rdtc.ru> Date: Wed, 13 Feb 2013 17:29:53 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Doug Hardie Subject: Re: Unusual TCP/IP Packet Size References: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org> In-Reply-To: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org, yongari@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, 13 Feb 2013 10:30:03 -0000 13.02.2013 17:25, Doug Hardie пишет: > Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has the following interface: > > msk0: flags=8843 metric 0 mtu 1500 > options=c011b > ether 00:11:2f:2a:c7:03 > inet 10.0.1.199 netmask 0xffffff00 broadcast 10.0.1.255 > inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1 > nd6 options=29 > media: Ethernet autoselect (100baseTX ) > status: active > > > It sent the following packet: (data content abbreviated) > > 02:14:42.081617 IP 10.0.1.199.443 > 10.0.1.2.61258: Flags [P.], seq 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr 920110183], length 3946 > 0x0000: 4500 0f9e ea89 4000 4006 2a08 0a00 01c7 E.....@.@.*..... > 0x0010: 0a00 0102 01bb ef4a ece1 680b ae37 1bbc .......J..h..7.. > 0x0020: 8018 0410 3407 0000 0101 080a 17f3 8ff8 ....4...……. > > > The indicated packet length is 3946 and the load of data shown is that size. The MTU on both interfaces is 1500. The receiving system received 3 packets. There is a router and switch between them. One of them fragmented that packet. This is part of a SSL/TLS exchange and one side or the other is hanging on this and just dropping the connection. I suspect the packet size is the issue. ssldump complains about the packet too and stops monitoring. Could this possibly be related to the hardware checksums? You have TSO enabled on the interface, so large outgoing TCP packet is pretty normal. It will be split by the NIC. Disable TSO with ifconfig if it interferes with your ssldump. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 12:19:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C1FE393 for ; Wed, 13 Feb 2013 12:19:23 +0000 (UTC) (envelope-from c47g@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by mx1.freebsd.org (Postfix) with ESMTP id 59B19E53 for ; Wed, 13 Feb 2013 12:19:23 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LiZpS-1UdZ4w0x2a-00ckin for ; Wed, 13 Feb 2013 13:19:22 +0100 Received: (qmail invoked by alias); 13 Feb 2013 12:19:22 -0000 Received: from cm56-168-232.liwest.at (EHLO bones.gusis.at) [86.56.168.232] by mail.gmx.net (mp034) with SMTP; 13 Feb 2013 13:19:22 +0100 X-Authenticated: #9978462 X-Provags-ID: V01U2FsdGVkX1+fb5cWsWKfC4OzV4V99WyPBQmv8sEuyiW+8o004N bEnPpbaNkyKI0H From: Christian Gusenbauer To: CeDeROM Subject: Re: 9.1 AMD64 multitasking efficiency low Date: Wed, 13 Feb 2013 13:21:49 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201302130844.45388.c47g@gmx.at> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201302131321.49429.c47g@gmx.at> X-Y-GMX-Trusted: 0 Cc: Bernhard =?iso-8859-1?q?Fr=F6hlich?= , freebsd-emulation@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, 13 Feb 2013 12:19:23 -0000 On Wednesday 13 February 2013 10:58:11 CeDeROM wrote: > I am not sure if this is the case of external drive, it only helped us > to figure out that problem is with writing to ICH SATA - WDC > configuration. It was also slow in 9.0 I guess, this is why I have > switched from Ext2 to UFS2 to get some speedup, so things are lets say > acceptable for the Atari fan =) > > Maybe the configuration of buffering/cache is wrong and can be fixed > easily with camcontrol but I have no experience with that, I have > started poking a bit but it coredumped, and I am not really keen to > misconfigura that drive and lose all data, so I prefer to wait for > someone with experience to come into discussion :-) > > Best regards :-) > Tomek Hi! It has something to do with the drive. I've just connected my external drive to the Intel controller and copied some GB of data around without performance impacts! So my new WDC drive works on both the JMicron and the Intel controller. Now we definitely need some help :-)! Any clues? Thanks, Christian. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 12:38:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ECD356F8; Wed, 13 Feb 2013 12:38:42 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by mx1.freebsd.org (Postfix) with ESMTP id 6EF69F38; Wed, 13 Feb 2013 12:38:42 +0000 (UTC) Received: by mail-qe0-f52.google.com with SMTP id 6so508966qeb.11 for ; Wed, 13 Feb 2013 04:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=PxlsrSlplCcUBo56caUwPhvNeLm73lR0At44gUvdx8U=; b=hv8mUMgAi3vswdMN9MokijwoN3wJlnqMEdoSGnMOr744PhUylGWHu142vkyCGf2N3R 1zhSpBkthRhthNgqQY7gQUv8xu2bVFNhZy4OndyuGeRen5VAZ4bX/UZQXDn8xtQKUrbl HTHpiArSA33AWWd7XR3w85hJ+xupXHn49VfBoTv9bhpxGMv14sv/vKAGE/2K/Ego7eeU 2pF5Vkf4+zwuiU1dKFn5oiQQL75BnjUn4ujT4SWeVzj//bZzM3SkOc8WouCZVNblwUFE cvP1xjk7IlfceK/T3B3szbM9X9kdvJdJjs60TyMEjpW66JHQgvPxR2ls1Y90uyYqni9W KNPQ== MIME-Version: 1.0 X-Received: by 10.49.59.48 with SMTP id w16mr9395117qeq.38.1360758653407; Wed, 13 Feb 2013 04:30:53 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Wed, 13 Feb 2013 04:30:53 -0800 (PST) In-Reply-To: <201302131321.49429.c47g@gmx.at> References: <201302130844.45388.c47g@gmx.at> <201302131321.49429.c47g@gmx.at> Date: Wed, 13 Feb 2013 13:30:53 +0100 X-Google-Sender-Auth: KZA7S0JeEuQdPv6t9mF7Pyf_Yro Message-ID: Subject: Re: 9.1 AMD64 multitasking efficiency low From: CeDeROM To: Christian Gusenbauer Content-Type: text/plain; charset=UTF-8 Cc: =?UTF-8?Q?Bernhard_Fr=C3=B6hlich?= , freebsd-emulation@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, 13 Feb 2013 12:38:43 -0000 On Wed, Feb 13, 2013 at 1:21 PM, Christian Gusenbauer wrote: > It has something to do with the drive. I've just connected my external drive > to the Intel controller and copied some GB of data around without performance > impacts! So my new WDC drive works on both the JMicron and the Intel > controller. On the other hand these drivers work very well on other operating systems like WIndows and Linux, so I would rather suspect some SCSI/CAM/SATA issues on the FreeBSD side...? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 12:42:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CDF0286A for ; Wed, 13 Feb 2013 12:42:58 +0000 (UTC) (envelope-from prvs=17563e53bc=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 54084F6C for ; Wed, 13 Feb 2013 12:42:58 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50002167515.msg for ; Wed, 13 Feb 2013 12:42:50 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 13 Feb 2013 12:42:50 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=17563e53bc=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <24F4479BCA224E028317665EE052273F@multiplay.co.uk> From: "Steven Hartland" To: "Teske, Devin" , "Daniel Braniss" References: <13CA24D6AB415D428143D44749F57D7201EA7586@ltcfiswmsgmb21>, <13CA24D6AB415D428143D44749F57D7201EA7B3E@ltcfiswmsgmb21> Subject: Re: ix? / Intel(R) PRO/10GbE Date: Wed, 13 Feb 2013 12:42:58 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 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: Wed, 13 Feb 2013 12:42:58 -0000 ----- Original Message ----- From: "Teske, Devin" > On Tue, 12 Feb 2013, Daniel Braniss wrote: > >> > On Tue, 12 Feb 2013, Daniel Braniss wrote: >> > >> > > I finally got a 10G card that is recognized by FreeBSD (9.1-stable): >> > > ... >> > > ix0: port >> > > 0xecc0-0xecdf mem 0xd9e80000-0xd9efffff,0xd9ff8000-0xd9ffbfff irq 40 at d=evice >> > > 0.0 on pci4 >> > > ix0: Using MSIX interrupts with 9 vectors >> > > ix0: RX Descriptors exceed system mbuf max, using default instead! >> > >> > From reading sys/dev/ixgbe/README: >> > >> > echo "kern.ipc.nmbclusters=262144" >> /etc/sysctl.conf >> > echo "kern.ipc.nmbjumbop=262144" >> /etc/sysctl.conf >> > reboot >> >> but this only works if the driver is loaded after >> the sysctl is executed! >> it's better to put it in /boot/loader.conf > > Not necessarily, it depends when the driver grabs the mbufs. In the case of the igb/ixgb/ixgbe drivers, this happens when the > interface is brought up (not when the driver is loaded, nor when the driver probes/attaches a PHY). In other words, you don't > have to worry about mbuf exhaustion until you say "ifconfig ix0 up" (in the case of ixgbe, bringing up even a single interface > is enough through the default mbufs and require more). > > Since sysctl.conf is processed before the network is brought up, putting the parameters in sysctl.conf will be perfectly > suitable for most needs (unless for some strange reason you need to "up" an interface before sysctl.conf is processed). That wasn't the case for ix for 8.3, not sure if its changed recently but without setting it in loader.conf the interface would error. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 13:01: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]) by hub.freebsd.org (Postfix) with ESMTP id 0157DC4E for ; Wed, 13 Feb 2013 13:01:02 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id DBEEED3 for ; Wed, 13 Feb 2013 13:01:01 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta01.emeryville.ca.mail.comcast.net with comcast id zovT1k00P0x6nqcA1p10Bx; Wed, 13 Feb 2013 13:01:00 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta12.emeryville.ca.mail.comcast.net with comcast id zp0z1k00L1t3BNj8Yp0z8R; Wed, 13 Feb 2013 13:01:00 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 34D4873A1C; Wed, 13 Feb 2013 05:00:59 -0800 (PST) Date: Wed, 13 Feb 2013 05:00:59 -0800 From: Jeremy Chadwick To: Eugene Grosbein Subject: Re: Unusual TCP/IP Packet Size Message-ID: <20130213130059.GA57337@icarus.home.lan> References: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org> <511B6B21.5030606@rdtc.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <511B6B21.5030606@rdtc.ru> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360760460; bh=bB4LtahistahWakz1xyRDtq0LftMJ3JflN4Tv68Vp7Y=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=YvXqvX6iJQNHIWOnBEWPmJzJeWo++JlfjFh87HoJIeIzhA7cBUW7n9+PBMFmG/WLR B+lMfGUDAx78CDs3qRPJunRUBBWXW+fRKV78X6fM4pL2gXERkvDViQ08CPDCpScoEk nX3SxNGqJV4OAbIqFMO8jCe19IKkB2vilT2SHTAUH4WCuklzbZgbcdHVBucia2PsOA 8EW3eeYfmS9AuR3fpGHJ1jSGnMG2bWzdj2qEd3AuWFlJzvidBXpnb4548uvUR/db2H wQPPBrsGPyFDsB5qziWnd3fi9cbGZehTT3LroEEVHyPTLGBG1jmBExp7gOe5AcxAdU gz8PM9Y67RCxg== Cc: freebsd-stable@freebsd.org, yongari@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, 13 Feb 2013 13:01:02 -0000 On Wed, Feb 13, 2013 at 05:29:53PM +0700, Eugene Grosbein wrote: > 13.02.2013 17:25, Doug Hardie ??????????: > > Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has the following interface: > > > > msk0: flags=8843 metric 0 mtu 1500 > > options=c011b > > ether 00:11:2f:2a:c7:03 > > inet 10.0.1.199 netmask 0xffffff00 broadcast 10.0.1.255 > > inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1 > > nd6 options=29 > > media: Ethernet autoselect (100baseTX ) > > status: active > > > > > > It sent the following packet: (data content abbreviated) > > > > 02:14:42.081617 IP 10.0.1.199.443 > 10.0.1.2.61258: Flags [P.], seq 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr 920110183], length 3946 > > 0x0000: 4500 0f9e ea89 4000 4006 2a08 0a00 01c7 E.....@.@.*..... > > 0x0010: 0a00 0102 01bb ef4a ece1 680b ae37 1bbc .......J..h..7.. > > 0x0020: 8018 0410 3407 0000 0101 080a 17f3 8ff8 ....4...??????. > > > > > > The indicated packet length is 3946 and the load of data shown is that size. The MTU on both interfaces is 1500. The receiving system received 3 packets. There is a router and switch between them. One of them fragmented that packet. This is part of a SSL/TLS exchange and one side or the other is hanging on this and just dropping the connection. I suspect the packet size is the issue. ssldump complains about the packet too and stops monitoring. Could this possibly be related to the hardware checksums? > > You have TSO enabled on the interface, so large outgoing TCP packet is pretty normal. > It will be split by the NIC. Disable TSO with ifconfig if it interferes with your ssldump. This is not the behaviour I see with em(4) on a 82573E with all defaults used (which includes TSO4). Note that Doug is using msk(4). I can provide packet captures on both ends of a LAN segment using both tcpdump (on the FreeBSD side) and Wireshark (on the Windows side) that show a difference in behaviour compared to what Doug sees. What I see on the FreeBSD side with tcpdump is repeated "bad-len 0" messages for payloads which are chunked or segmented as a result of TSO. I do not see a 1:1 ratio of "bad-len" entries to chunked payloads; I only see one "bad-len" entry for all chunks (up until the next ACK or PSH+ACK of course). The important part: I do not see captured TCP packets reporting a length greater than MTU (or MSS for that matter (remember: IP header + TCP header + MSS <= MTU). Also note for Doug: remember that if you're doing packet captures between two devices that have NAT involved, you may see different behaviour. Example case: 03:58:47.907582 IP 67.180.84.87.2983 > 206.125.172.42.80: Flags [.], ack 13419, win 64240, length 0 03:58:47.907649 IP 206.125.172.42.80 > 67.180.84.87.2983: Flags [.], seq 17799:19259, ack 292, win 1026, length 1460 03:58:47.907679 IP 206.125.172.42.80 > 67.180.84.87.2983: Flags [.], seq 19259:20719, ack 292, win 1026, length 1460 03:58:47.912546 IP 67.180.84.87.2983 > 206.125.172.42.80: Flags [.], ack 16339, win 64240, length 0 In the above example there's a Linux NAT router (67.180.84.87) with a client (192.168.1.50) behind it, talking to 206.125.172.42. MTU is 1500 (I obviously didn't include the initial SYN :-) ). -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 13:04:26 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F1B1DD7C; Wed, 13 Feb 2013 13:04:25 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7BF101; Wed, 13 Feb 2013 13:04:25 +0000 (UTC) Received: by mail-qe0-f41.google.com with SMTP id 7so518697qeb.14 for ; Wed, 13 Feb 2013 05:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=K7vMwPGCrVukN3qRJmNOF6LSFikfTaMaDY7Gf3bj49c=; b=hess7L6PLYzweFeDqIZ7UchQBeoSEunxzHueSV7wyaw6KbdSDTBPG0rhgPo5MtxZDd Mcthz8lr2y9Z44jc10WyNfdMo472UtUhHBDRQQD306Chty6ACs+FGQskpN6s2c2oWwOc R7FWud8dCV5m8VpKZJy1+VDmhJQ5YAW+Wy/ihMcOS9VowiVdm+5TnwHo7nzp0mmi3XsJ JlPk4+N2jUjeGJJdx/G3sgDJrWjcRJpXuD0N24F5lKtW8kdzULon7bnZdSNEZgcodjJv oPNlyk2+Bk3pq7HDNvTBKfGvSYIZIqbBZ4MCairIR89Bsb8cNClKj49zlLJFFTYFx99E Z18A== MIME-Version: 1.0 X-Received: by 10.229.177.14 with SMTP id bg14mr1991868qcb.51.1360760664491; Wed, 13 Feb 2013 05:04:24 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Wed, 13 Feb 2013 05:04:24 -0800 (PST) In-Reply-To: References: <201302130844.45388.c47g@gmx.at> <201302131321.49429.c47g@gmx.at> Date: Wed, 13 Feb 2013 14:04:24 +0100 X-Google-Sender-Auth: AQmZrpt-P9PbXqjf6uFAvGiaZf4 Message-ID: Subject: Re: 9.1 AMD64 multitasking efficiency low From: CeDeROM To: Christian Gusenbauer Content-Type: text/plain; charset=UTF-8 Cc: =?UTF-8?Q?Bernhard_Fr=C3=B6hlich?= , freebsd-emulation@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, 13 Feb 2013 13:04:26 -0000 Guys can you please check if you have HAL daemon running? When I switched it off my system got some hickups but is far more responsive.. maybe this is another cause? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 13:48:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B7E758CF for ; Wed, 13 Feb 2013 13:48:02 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by mx1.freebsd.org (Postfix) with ESMTP id 9B3812F9 for ; Wed, 13 Feb 2013 13:48:02 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta12.emeryville.ca.mail.comcast.net with comcast id zpFQ1k0051eYJf8ACpo29N; Wed, 13 Feb 2013 13:48:02 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta19.emeryville.ca.mail.comcast.net with comcast id zpo11k0061t3BNj01po1v4; Wed, 13 Feb 2013 13:48:02 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 481C973A1C; Wed, 13 Feb 2013 05:48:01 -0800 (PST) Date: Wed, 13 Feb 2013 05:48:01 -0800 From: Jeremy Chadwick To: CeDeROM Subject: Re: 9.1 AMD64 multitasking efficiency low Message-ID: <20130213134801.GA58535@icarus.home.lan> References: <201302130844.45388.c47g@gmx.at> <201302131321.49429.c47g@gmx.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360763282; bh=zG7vPWmpEoQCwYJL1Peop5avoU5Zht7zLPKpoI5Mo5Y=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=snM6ybj09UoW2OnTpz9cD5TYS/SaftnihhAnlATfv+tg693UjnmLIwwapkVKkFf8M pNEv/QIYLp8ZE6zRdptiip8vEqcapdwSzZOFsO+DAivBfOLYzwkDXfmiTbe/60jGMC Fhq43jk9/GHITZHOL/MC8RcRamQtU7D3caybORrO31EyjAxXDOYltfiWytSzlWUEnH KiUirTsx6K3TZYOrMjKtnfi62ai+4gCs1q+Fpvn3QMBnzvaIwRzqWDgygFcDJIkFP2 iqMR9PwpEetLPL9dZDUW187YyX+TjgYLTt7iTx9V7bjhJQssq/dLsA/336AHLd2Rjm +UWSc6dk6SajQ== Cc: freebsd-stable@freebsd.org, freebsd-emulation@freebsd.org, Bernhard Fr??hlich X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Feb 2013 13:48:02 -0000 On Wed, Feb 13, 2013 at 01:30:53PM +0100, CeDeROM wrote: > On Wed, Feb 13, 2013 at 1:21 PM, Christian Gusenbauer wrote: > > It has something to do with the drive. I've just connected my external drive > > to the Intel controller and copied some GB of data around without performance > > impacts! So my new WDC drive works on both the JMicron and the Intel > > controller. > > On the other hand these drivers work very well on other operating > systems like WIndows and Linux, so I would rather suspect some > SCSI/CAM/SATA issues on the FreeBSD side...? I'm stepping in. This thread is officially pissing me off. I have read the thread. Every post. Repeatedly. I went back and read them all. Again: every one. I see all the nuances, all the stuff you're screwing with, all the stuff you're changing between posts. All I see are random, wild, insane claims of "SATA/AHCI/CAM issues" or "WDC disks have problems" or "maybe it's the Intel controller". Nobody until half way through the thread mentioned that USB was involved (heh heh heh...), nor did anyone disclose that the "system" in question was a laptop (it matters). Others with different setups are posting "me too!" yet their issue may be completely different. I see no actual useful data being posted either, just all sorts of vague statements; I find this very bizarre given that this is a UNIX OS and a UNIX-related mailing list, yet data is omitted. And now we have "are you running hald? Guys try shutting it off". Stop this madness. STOP IT. Stop being (what appears to be) hyperactive and sit down and actually FIGURE OUT when the issue begins for you. It will take you hours, if not an entire day, to do proper analysis of this. You will have to try numerous things -- and you will need to take very precise, very meticulous notes during each thing you do. You will have to reboot the machine numerous times, because filesystem caching may be causing you complications. Stop involving other hardware ("a more powerful machine"). Focus on ONE MACHINE, do not bring other things into the mix. Stop using ext2fs. Use UFS2, and state whether or not you're using SU, and/or SU+J. It matters. Provide dmesg output from the machine in question (straight off a fresh reboot), with the USB drive attached. Provide "pciconf -lvbc" output from that machine. Provide "gpart show" output for each drive. Provide SMART statistics for the hard disks involved (the USB one, as well as the internal one). ports/sysutils/smartmontools. smartctl -a output is what I want. If you can't get the data from the USB one (you may have to use "smartctl --scan" and try its flag recommendations), get a different USB enclosure that has a USB/SATA bridge that permits SMART pass-through. At some point (your choice -- come up with a plan!) take the USB drive out of the picture. Add a 2nd internal drive and try doing I/O to/from that instead. Figure it out. And finally -- start using "gstat -I500ms" in another VTY -- when using the system. This will give you some idea of the I/O workload that's going on, on a per-device level. If you see a device that should be getting, say, 150MBytes/second yet is only get 7MBytes/second, then that may be an indication of where to focus. If you want an example of a bug that took me an afternoon to track down, and a good 30-40 reboots and having to take audio recordings (pocket recorder) while performing physical tasks, just to figure out how to reproduce the problem, here you go: http://lists.freebsd.org/pipermail/freebsd-fs/2013-January/016324.html *That* is what is needed here. I am more than happy to help you analyse problems relating to hard disk performance -- I can assure you CAM/ahci(4) and related bits are in good shape, barring weird/bizarre chipset revision oddities (common with the mobile chipset versions, i.e. ICHxxM) -- but the information needs to be provided coherently. Take an afternoon to figure out what the commonality is. I can expand on all sorts of levels about hard disk performance, all the way down to PCB cache going bad or excessive ECC impacting things, but there's no point in speculating or going there until evidence shows that. And please, no "me too" posts. As said, each issue should be treated separately. Figure out where the commonality is through trial and error, then post those results here. Nobody can help when arms are flailing to this degree. Got it? -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 14:15:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D556D4FC; Wed, 13 Feb 2013 14:15:46 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by mx1.freebsd.org (Postfix) with ESMTP id 789986C5; Wed, 13 Feb 2013 14:15:46 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id bv4so2160154qab.10 for ; Wed, 13 Feb 2013 06:15:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jo/UigzN+LDtJYsmL3+2acozLLPhnWUk3/ZgbkDOnw8=; b=WtCGvTsE60m3VE6bjX7H2oB0hkrNj/IWNcV/1f/1OvTVV3+kkvv+GpFNWgYdmIUmEa ZverajYCZrungvMfbX2yE6zUVvzVlBTf3j2XAGt0Cg47IufQM2ilkyH77TN87m4awMlm LXENS3/cHv9oVGYSuVBbp2v28uEiAnBE9lIn6CapfQGeGSyvHa2uOCgtbjItq7PkqUPT 4h4kGgadDC9Oxf6CAURbc0z1cfcB2ORtckyOPdJ8fkdriDRdRGKCm/J4+ACR4huZOWfB eAfcJQb6DNFjEzbfG/+k/lqaq3uY3tbx/g3ge5DPYd2XwbW1sexhhgp1Zz9OMeeT+ny5 gfog== MIME-Version: 1.0 X-Received: by 10.229.173.67 with SMTP id o3mr1950532qcz.113.1360764935050; Wed, 13 Feb 2013 06:15:35 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Wed, 13 Feb 2013 06:15:34 -0800 (PST) In-Reply-To: <20130213134801.GA58535@icarus.home.lan> References: <201302130844.45388.c47g@gmx.at> <201302131321.49429.c47g@gmx.at> <20130213134801.GA58535@icarus.home.lan> Date: Wed, 13 Feb 2013 15:15:34 +0100 X-Google-Sender-Auth: XfUQP_LOlBDqTZPetdxbJYkoVlI Message-ID: Subject: Re: 9.1 AMD64 multitasking efficiency low From: CeDeROM To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, freebsd-emulation@freebsd.org, Bernhard Fr??hlich X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 13 Feb 2013 14:15:46 -0000 Hello Jeremy :-) Thanks for your constructive critics :-) "Me too" is also important because it shows we do no hallucinate and the video shows the problem is real so we try to get common denominator :-) :-) I will be back from delegation this weekend and I will provide more useful data from both machines, please specify what input information can help you sort things out, as you can see we need some support on this :-) Thank you! :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 14:50:31 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 362E1D40 for ; Wed, 13 Feb 2013 14:50:31 +0000 (UTC) (envelope-from olli@grabthar.secnetix.de) Received: from grabthar.secnetix.de (grabthar.secnetix.de [212.17.241.225]) by mx1.freebsd.org (Postfix) with ESMTP id BEFD3819 for ; Wed, 13 Feb 2013 14:50:30 +0000 (UTC) Received: from grabthar.secnetix.de (localhost [127.0.0.1]) by grabthar.secnetix.de (8.14.5/8.14.5) with ESMTP id r1DEoGLH098021; Wed, 13 Feb 2013 15:50:23 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by grabthar.secnetix.de (8.14.5/8.14.5/Submit) id r1DEoGb3098019; Wed, 13 Feb 2013 15:50:16 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <201302131450.r1DEoGb3098019@grabthar.secnetix.de> Subject: Re: re(4) problems with GA-H77N-WIFI To: pyunyh@gmail.com Date: Wed, 13 Feb 2013 15:50:16 +0100 (CET) In-Reply-To: <20130213013438.GA3101@michelle.cdnetworks.com> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@FreeBSD.ORG X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 14:50:31 -0000 YongHyeon PYUN wrote: > On Fri, Feb 08, 2013 at 08:27:55PM +0100, Oliver Fromme wrote: > > re0: CMD 0x0c > > re0: link state changed to UP > > re0: link state changed to DOWN > > re1: link state changed to UP > > re1: link state changed to DOWN > > re1: CMD 0x0c > > re1: link state changed to UP > > re0: CMD 0x0c > > re0: link state changed to UP > > re1: link state changed to DOWN > > > > I always seem to get 0x0c for both re0 and re1. > > Hmm, it seems GMAC is in sane state. > Would you show me the output of "devinfo -rv | grep rgephy"? rgephy0 pnpinfo oui=0xe04c model=0x11 rev=0x5 at phyno=1 rgephy1 pnpinfo oui=0xe04c model=0x11 rev=0x5 at phyno=1 > To rule out hardware issues, could you also try other OS like > Linux? Ok, I'll look for a small Linux image that can be booted from a USB stick ... Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Handelsregister: Amtsgericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsreg.: Amtsgericht München, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen/-Produkte + mehr: http://www.secnetix.de/bsd "I invented Ctrl-Alt-Delete, but Bill Gates made it famous." -- David Bradley, original IBM PC design team From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 16:00:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C52AEE08 for ; Wed, 13 Feb 2013 16:00:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A3234C05 for ; Wed, 13 Feb 2013 16:00:04 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0A72CB9A1; Wed, 13 Feb 2013 11:00:04 -0500 (EST) From: John Baldwin To: CeDeROM Subject: Re: 9.1-RELEASE AMD64 crash under VBox 4.2.6 when IO APIC is disabled Date: Wed, 13 Feb 2013 10:48:06 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201302111606.06731.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201302131048.06370.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 13 Feb 2013 11:00:04 -0500 (EST) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:00:04 -0000 On Monday, February 11, 2013 4:34:37 pm CeDeROM wrote: > On Mon, Feb 11, 2013 at 10:06 PM, John Baldwin wrote: > > On Sunday, February 10, 2013 1:16:16 pm CeDeROM wrote: > >> Hey :-) I have just noticed that booting installation media for > >> FreeBSD 9.1-RELEASE AMD64 from ISO bootonly under VirtualBox 4.2.6 > >> results in a kernel panic both when ACPI is enabled and disabled in > > > > You will need to add 'device atpic' to your kernel config and build a custom > > kernel. All real amd64-capable hardware has APICs. > > Hello John :-) Thank you for your reply, still I need some more > information to understand why this happens :-) > > The simple answer that I have deduced is that APIC is MANDATORY for > AMD64 machines and they won't run otherwise? This is why generic AMD64 > install fails when no APIC is enabled in the VBox? No, it is not quite like that. x86 machines have two entirely different sets of interrupt controllers. Old i386 machines only had a pair of 8259A controllers (this is what 'device atpic' manages), and i386 kernels assume they are always present (see sys/i386/conf/DEFAULTS). When Intel added SMP support to i386 machines starting with the 486 and Pentium they added a new set of interrupt controllers called APICs (both I/O APICs to manage device interrupts ala the 8259As and on-CPU APICs on Pentium and later called local APICs). "device apic" enables use of APICs. The code to manage these is actually shared between i386 and amd64 and any x86 kernel can use one or the other of these _if_ the relevant driver is compiled in. On i386 'device atpic' is enabled by default (via DEFAULTS) and 'device apic' is enabled in GENERIC, so i386 kernels will work with both out of the box. On amd64, 'device atpic' is not enabled by default (not in GENERIC), but 'device apic' is mandated to be on (it's not even an option, just always compiled in). So GENERIC on amd64 only supports 'device apic' by default. You can use 'device atpic' on amd64 if you really want to, but APICs are more efficient and required for using multiple CPUs, so unless you are working around a specific hardware bug (or writing a hypervisor where you haven't implemented APIC emulation yet), you should prefer APIC. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 16:41:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7B1FF2B2; Wed, 13 Feb 2013 16:41:20 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:8:bdbe:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id B2B21EF0; Wed, 13 Feb 2013 16:41:19 +0000 (UTC) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:8:bdbe:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 3Z5mhW5JdZzHdJ; Wed, 13 Feb 2013 17:41:15 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.7.4 tignes.restart.be 3Z5mhW5JdZzHdJ DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=restart.be; s=tignes; t=1360773675; bh=0yQh2xniRVRtY6iQ45jY4vDVvaMbSYf3JgyFKSa34/8=; h=Date:From:To:Subject:References:In-Reply-To; z=Date:=20Wed,=2013=20Feb=202013=2017:41:14=20+0100|From:=20Henri=2 0Hennebert=20|To:=20freebsd-current@freebsd.org,=2 0freebsd-stable@freebsd.org|Subject:=20Re:=20sysctl=20-a=20causes= 20kernel=20trap=2012|References:=20<50EB602F.9050300@delphij.net>= 20<20130108000233.GZ82219@kib.kiev.ua>=20<50EB63A9.50903@delphij.n et>=20=20<50EB870D.3020306@delphij.net>=20<50EF3FEC.60605@delphi j.net>=20=20<50F9B70A.5040305@delphij.net>=20=20<511A25EC. 8070000@restart.be>|In-Reply-To:=20<511A25EC.8070000@restart.be>; b=kxOcpFVr3SEEtQia6Oc9ds1ZGwGkLzoBQx9DG7Cm5Cys60V3TfyvX+5I++B8gK6e6 2DAQ5oX3WteGhgpLAFGkdMu1RGY7aiV//gJeIZ7HW8qujA4KnM+fDOIGBklWZOcDxU DNoHfzalxZhzfzz9somuPsLkLSx4lRZRSSzA+yXXebXAOKDZoyWpTv1skVnJ6rWpA2 a2f2hhnAHgDFx/kd3GoTa8Rgzz/LiTaWW6VpRpXnE+jkYBK72DbzjndQ7O8BY3BjA7 CIxARviO3PcGPfWnr1qOAZWu6Oa+/1yTZO4xsn6JfGK00n7WRJFeWXlkmQSC2qLaBz bp8lFl8QzK6bw== Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:8:bdbe:1:2::]) (authenticated bits=0) by restart.be (8.14.6/8.14.5) with ESMTP id r1DGfEV0068060; Wed, 13 Feb 2013 17:41:15 +0100 (CET) (envelope-from hlh@restart.be) Message-ID: <511BC22A.1030701@restart.be> Date: Wed, 13 Feb 2013 17:41:14 +0100 From: Henri Hennebert Organization: RestartSoft User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130207 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: sysctl -a causes kernel trap 12 References: <50EB602F.9050300@delphij.net> <20130108000233.GZ82219@kib.kiev.ua> <50EB63A9.50903@delphij.net> <50EB870D.3020306@delphij.net> <50EF3FEC.60605@delphij.net> <50F9B70A.5040305@delphij.net> <511A25EC.8070000@restart.be> In-Reply-To: <511A25EC.8070000@restart.be> Content-Type: text/plain; charset=ISO-8859-1 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, 13 Feb 2013 16:41:20 -0000 On 02/12/2013 12:22, Henri Hennebert wrote: > On 01/19/2013 06:58, Brandon Gooch wrote: >> On Fri, Jan 18, 2013 at 2:56 PM, Xin Li wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>> >>> On 01/18/13 12:50, Brandon Gooch wrote: >>>> On Thu, Jan 10, 2013 at 4:25 PM, Xin Li >>> > wrote: >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>> >>>> To all: this became more and more hard to replicate lately. I've >>>> tried these options and the most important progress is that it's >>>> possible to get a crashdump when debug.debugger_on_panic=0 and I >>>> managed to get a backtrace which indicates the panic occur when >>>> trying to do mtx_lock(&Giant) -> __mtx_lock_sleep -> turnstile_wait >>>> -> propagate_priority, but after I've added some instruments to >>>> the surrounding code and enabled INVARIANT and/or WITNESS, it >>>> mysteriously went away. >>>> >>>> Reverting my instruments code and update to latest svn makes the >>>> issue disappear for one day. I've hit it again today but >>>> unfortunately didn't get a successful dump and after reboot I can't >>>> reproduce it again :( >>>> >>>> Still trying... >>>> >>>> >>>> Any updates Xin? >>> >>> No, it mysteriously disappeared for now. According to my >>> understanding to recent svn commits, I didn't see anybody committing >>> something that fixes it but I can no longer panic my system, with or >>> without debugging code :( >>> >>>> I was actually hitting what I believe to be exactly the same issue >>>> as you on one of my systems, and, as you've seen, adding any extra >>>> debugging or diagnostics seemed to eliminate the issue. >>>> >>>> I was able to generate quite a few vmcores and still have these >>>> sitting around in my filesystem (along with the kernels that helped >>>> produce them). >>>> >>>> I can recreate this crash on my system by compiling the NVIDIA >>>> driver with clang at -01 and above. Although it's been noted that >>>> this issue has been seen in scenarios without an NIVIDIA driver in >>>> the mix, whatever is happening in the kernel to cause the panic is >>>> somehow triggered by this, at least on my system. >>> >>> I'm not sure if this is the same problem. Could you please try using >>> gcc to compile the nVIdia driver and see if that "fixes" the problem? >>> >>> Cheers, >>> - -- >>> Xin LI https://www.delphij.net/ >>> FreeBSD - The Power to Serve! Live free or die >>> >> >> Indeed, a gcc compiled NVIDIA module eliminates the issue, sorry if I >> hadn't mentioned this earlier. >> >> What was happening to me at first was that my system would just hang while >> booting. I was able to figure out that it was during /etc/rc.d/initrandom. >> I actually got to a point where I removed the call to sysctl -a from >> 'better_than_nothing()' in /etc/rc.d/initrandom to have a booting system. I >> finally had a situation where I could get a panic by adding SW_WATCHDOG to >> my kernel and running watchdogd(8). >> >> For me, this panic would come and go seemingly at random as well, and I >> couldn't fumble my way around in the debugger to learn much of anythingfreebsd-current@freebsd.org >> when I first started seeing it. I just started a process of modularizing >> everything I could in my kernel config, then loading modules 1-by-1 and >> booting over-and-over until I finally found what appeared to be the >> problem, which was the NVIDIA module compiled with clang. >> >> Oh, another thing: at times it seemed as though it was the number of >> modules loaded, as I could get the hang with 41 modules loaded, but not 40 >> or 42?! I admit, when I was seeing that behavior, I hadn't eliminated the >> NVIDIA driver from my loaded modules. I need to revisit the panic situation >> to confirm this particular strangeness. >> >> Here's the last panic I had: >> >> Unread portion of the kernel message buffer: >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 1175 (sysctl) >> >> (kgdb) bt >> #0 doadump (textdump=1694704112) at pcpu.h:229 >> #1 0xffffffff802fab82 in db_fncall (dummy1=, >> dummy2=, dummy3=, dummy4=> optimized out>) at /usr/src/sys/ddb/db_command.c:578 >> #2 0xffffffff802fa85a in db_command (last_cmdp=, >> cmd_table=, dopager=1) at >> /usr/src/sys/ddb/db_command.c:449 >> #3 0xffffffff802fa612 in db_command_loop () at >> /usr/src/sys/ddb/db_command.c:502 >> #4 0xffffffff802fcf60 in db_trap (type=, code=0) at >> /usr/src/sys/ddb/db_main.c:231 >> #5 0xffffffff804a7b93 in kdb_trap (type=12, code=0, tf=> out>) at /usr/src/sys/kern/subr_kdb.c:654 >> #6 0xffffffff807157c5 in trap_fatal (frame=0xffffff8865032670, eva=> optimized out>) at /usr/src/sys/amd64/amd64/trap.c:867 >> #7 0xffffffff80715adb in trap_pfault (frame=0x0, usermode=0) at >> /usr/src/sys/amd64/amd64/trap.c:698 >> #8 0xffffffff8071529b in trap (frame=0xffffff8865032670) at >> /usr/src/sys/amd64/amd64/trap.c:463 >> #9 0xffffffff806ff382 in calltrap () at exception.S:228 >> #10 0xffffffff8047bd50 in sysctl_sysctl_next_ls (lsp=, >> name=0xffffff8865032a80, namelen=, >> next=0xffffff8865032898, len=0xffffff8865032904, level=3) at >> /usr/src/sys/kern/kern_sysctl.c:759 >> #11 0xffffffff8047be5e in sysctl_sysctl_next_ls (lsp=0xfffffe000d3f0080, >> name=0xffffff8865032a7c, namelen=, >> next=0xffffff8865032894, len=0xffffff8865032904, level=2) at >> /usr/src/sys/kern/kern_sysctl.c:786 >> #12 0xffffffff8047be5e in sysctl_sysctl_next_ls (lsp=0xfffffe000d3f0080, >> name=0xffffff8865032a78, namelen=, >> next=0xffffff8865032890, len=0xffffff8865032904, level=1) at >> /usr/src/sys/kern/kern_sysctl.c:786 >> #13 0xffffffff8047bca3 in sysctl_sysctl_next (oidp=, >> arg1=0xffffff8865032a78, arg2=4, req=0xffffff88650329a8) at >> /usr/src/sys/kern/kern_sysctl.c:808 >> #14 0xffffffff8047b03f in sysctl_root (arg1=, >> arg2=) at /usr/src/sys/kern/kern_sysctl.c:1513 >> #15 0xffffffff8047b5d8 in userland_sysctl (td=, >> name=0xffffff8865032a70, namelen=, old=> optimized out>, oldlenp=, inkernel=> out>, new=, newlen=, >> retval=, flags=1694706064) at >> /usr/src/sys/kern/kern_sysctl.c:1623 >> #16 0xffffffff8047b3c4 in sys___sysctl (td=0xfffffe001e2d4900, >> uap=0xffffff8865032b80) at /usr/src/sys/kern/kern_sysctl.c:1549 >> #17 0xffffffff807160f7 in amd64_syscall (td=0xfffffe001e2d4900, traced=0) >> at subr_syscall.c:135 >> #18 0xffffffff806ff66b in Xfast_syscall () at exception.S:387 >> #19 0x000000080093697a in ?? () >> Previous frame inner to this frame (corrupt stack?) >> Current language: auto; currently minimal >> >> Any ideas on where to look through this vmcore? >> >> -Brandon > > FWIW > > Just going from 9.1-STABLE r245423M to 9.1-STABLE #0 r246457M trigger > this problem. > > I drop sysctl -a from /etc/rc.d/initrandom and all is back to normal. > > I have nvidia-driver-304.64 compiled with gcc as for all my ports. > > Henri Just a follow up: sysctl hw.nvidia generate a page fault: morzine.restart.bel dumped core - see /var/crash/vmcore.86 Wed Feb 13 17:29:14 CET 2013 FreeBSD morzine.restart.bel 9.1-STABLE FreeBSD 9.1-STABLE #0 r246457M: Thu Feb 7 15:09:16 CET 2013 root@morzine.restart.bel:/usr/obj/usr/src/sys/MORZINE i386 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 "i386-marcel-freebsd"... Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x20:0xa07647d4 stack pointer = 0x28:0xfd1f0ac8 frame pointer = 0x28:0xfd1f0aec code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 2369 (sysctl) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper(a0a44a64,0,70617200,46,fc,...) at db_trace_self_wrapper+0x2d/frame 0xfd1f07c0 kdb_backtrace(a0a760c5,1,a0a0bc3c,fd1f087c,1,...) at kdb_backtrace+0x30/frame 0xfd1f0828 panic(a0a0bc3c,a0a76eaf,cfcb0d74,1,1,...) at panic+0x1bb/frame 0xfd1f0870 trap_fatal(fd1f0900,a09d2ee1,a0b17130,b5592000,0,...) at trap_fatal+0x33a/frame 0xfd1f08c0 trap_pfault(14,c,1,ffffffff,fd1f0994,...) at trap_pfault+0x31d/frame 0xfd1f0940 trap(fd1f0a88) at trap+0x4ef/frame 0xfd1f0a7c calltrap() at calltrap+0x6/frame 0xfd1f0a7c --- trap 0xc, eip = 0xa07647d4, esp = 0xfd1f0ac8, ebp = 0xfd1f0aec --- turnstile_broadcast(0,0,a7b80b40,0,fd1f0b38,...) at turnstile_broadcast+0xa4/frame 0xfd1f0aec _mtx_unlock_sleep(a0b6a00c,0,0,0,fd1f0b58,...) at _mtx_unlock_sleep+0x57/frame 0xfd1f0b04 sysctl_root(fd1f0b58,fd1f0b64,4,a09c87fe,bfc0d450,...) at sysctl_root+0x248/frame 0xfd1f0b38 userland_sysctl(cfcb0bc0,fd1f0bd4,5,0,9fbfca2c,...) at userland_sysctl+0x1da/frame 0xfd1f0b9c sys___sysctl(cfcb0bc0,fd1f0cc8,1,fd1f0cb0,0,...) at sys___sysctl+0x95/frame 0xfd1f0c40 syscall(fd1f0d08) at syscall+0x452/frame 0xfd1f0cfc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xfd1f0cfc --- syscall (202, FreeBSD ELF32, sys___sysctl), eip = 0x33d65f6b, esp = 0x9fbfc9e4, ebp = 0x9fbfd2ac --- Uptime: 5h45m16s Physical memory: 3046 MB (kgdb) #0 doadump (textdump=1) at pcpu.h:249 #1 0xa071b78a in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0xa071bc17 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:636 #3 0xa09cc21a in trap_fatal (frame=, eva=20) at /usr/src/sys/i386/i386/trap.c:1043 #4 0xa09cc54d in trap_pfault (frame=0x0, usermode=, eva=0) at /usr/src/sys/i386/i386/trap.c:858 #5 0xa09cbb3f in trap (frame=0xfd1f0a88) at /usr/src/sys/i386/i386/trap.c:555 #6 0xa09b5c0c in calltrap () at exception.s:169 #7 0xa07647d4 in turnstile_broadcast (ts=0x0, queue=0) at /usr/src/sys/kern/subr_turnstile.c:837 #8 0xa0707217 in _mtx_unlock_sleep (m=0xa0b6a00c, opts=-48297228, file=0xfd1f0af4 "", line=-48297228) at /usr/src/sys/kern/kern_mutex.c:715 #9 0xa0728418 in sysctl_root (arg1=, arg2=) at /usr/src/sys/kern/kern_sysctl.c:1515 #10 0xa072899a in userland_sysctl (td=0x4, old=, oldlenp=, inkernel=, new=, newlen=, retval=, flags=-1603107360) at /usr/src/sys/kern/kern_sysctl.c:1623 #11 0xa0728785 in sys___sysctl (uap=0xfd1f0cc8) at /usr/src/sys/kern/kern_sysctl.c:1549 #12 0xa09ccc22 in syscall (frame=) at subr_syscall.c:135 #13 0xa09b5ca1 in Xint0x80_syscall () at exception.s:267 #14 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal Henri From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 20:30:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B291DDD; Wed, 13 Feb 2013 20:30:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0E2CFDC7; Wed, 13 Feb 2013 20:30:52 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1DKUgc6051949; Wed, 13 Feb 2013 22:30:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1DKUgc6051949 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1DKUgfY051948; Wed, 13 Feb 2013 22:30:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 13 Feb 2013 22:30:42 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: 9-STABLE -> NFS -> NetAPP: Message-ID: <20130213203042.GW2522@kib.kiev.ua> References: <61DAA500-EB20-4861-AA7F-402FF1047B81@hub.org> <339364797.2960794.1360720239431.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nk8TfLPx+OTa8gAE" Content-Disposition: inline In-Reply-To: <339364797.2960794.1360720239431.JavaMail.root@erie.cs.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: Marc Fournier , Kostik Belousov , freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 20:30:53 -0000 --nk8TfLPx+OTa8gAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 12, 2013 at 08:50:39PM -0500, Rick Macklem wrote: > Marc Fournier wrote: > > Just reset server, so any further details will have to be 'next time' > > ??? but, just did a csup and am rebuilding ??? the following three files > > were modified since last build: > >=20 > > grep nfs /tmp/output > > Edit src/sys/fs/nfs/nfs_commonsubs.c > > Edit src/sys/fs/nfsclient/nfs_clrpcops.c > > Edit src/sys/fs/nfsserver/nfs_nfsdserv.c > >=20 > >=20 > > On 2013-02-10, at 4:56 PM, Marc Fournier wrote: > >=20 > > > > > > On 2013-02-10, at 4:31 PM, Rick Macklem > > > wrote: > > > > > >> Marc Fournier wrote: > > >>> Hi John ??? > > >>> > > >>> Does this help? > > >>> > > >>> root@io:~ # ps auxl | grep du > > >>> root 1054 0.0 0.1 16176 6600 ?? D 3:15AM 0:05.38 du -skx /vm/2799 > > >>> 0 > > >>> 81426 0 20 0 newnfs > > >>> root 12353 0.0 0.1 16176 5104 ?? D Sat03AM 0:05.41 du -skx > > >>> /vm/2799 0 > > >>> 91597 0 20 0 newnfs > > >>> root 64529 0.0 0.1 16176 5164 ?? D Fri03AM 0:05.40 du -skx > > >>> /vm/2799 0 > > >>> 43227 0 20 0 newnfs > > >>> root 12855 0.0 0.0 16308 1988 0 S+ 5:26AM 0:00.00 grep du 0 12847 > > >>> 0 20 > > >>> 0 piperd > > >> It is probably too late, but all the lines (without the | grep du) > > >> would be > > >> more useful. I also include the "H" flag, so it lists threads as > > >> well as > > >> processes. The above just says the "du" command is waiting for a > > >> vnode lock. > > >> The interesting process/thread is the one that is holding a vnode > > >> lock > > >> while waiting for something else. > > > > > > As requested, 'ps auxlH' attached ??? > > > > > > > > > > > > > Well, I took a look at the ps output and I didn't see anything that would > identify what the hang is. There are a lot of processes sleeping on "newn= fs" > (waiting for a vnode lock) and many sleeping on "vofflock" (waiting for t= he > f_offset lock). I never got any attachments on the thread. See http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel= debug-deadlocks.html for the description of what is needed to start debugging. >=20 > Unfortunately, I can't spot any process/thread that is blocked on somethi= ng > else, where it would seem likely to be holding either an nfs vnode lock or > f_offset lock that isn't one of these. >=20 > There were changes about 5 months ago which it appears fixed a deadlock r= ace > between vnode locks and offset locks for paging (r236321 and friends). No, I do not think that the description of the changes is right. >=20 > I am wondering if there could be other similar races, possibly specific to > paging in over NFS? (I can't see any case where there is a LOR, so I can't > think of what it might be?) >=20 > If you just want the hangs to go away, I'd suggest moving the executable > is /usr/local/sbin (httpd maybe) to a local file system on the server, > since it does seem to be related to paging this executable in over NFS. >=20 > rick > ps: I've added kib@ to the cc, in case he is aware of other related races? >=20 > > >> > > >> Are you still getting the: > > >> nfs_getpages: error 13 > > >> vm_fault: pager read error, pid 11355 (https) > > > > > > Fairly quiet: > > > > > > > > > > > > And that is it since last reboot ~20 days ago ??? > > > > > >> > > >> messages logged? > > >> > > >> With John's recent patch, the error# would no longer be 13 if it > > >> was > > >> caused by the "intr" flag resulting in a Read RPC terminating with > > >> EINTR. > > >> If you are still getting the above with "error 13", it suggests > > >> that > > >> the server is replying EACCES for the Read RPC. > > >> I suggested before that you check to make sure that the executable > > >> had > > >> read access for everyone one the file server. Since I didn't hear > > >> back, > > >> I'll assume this is the case. > > > > > > Don't understand this question ??? I have 34 VPSs running off of this > > > server right now ??? that 'du process' runs against each of those VPSs > > > every night, and this problem started happening on Friday night's > > > run ??? ~18 days into uptime ??? so the same process has run repeated= ly, > > > with no issues, 18 times before it hung on Friday ??? also, the hang, > > > once 'triggered', only seems to recur against the same directory ??? > > > the same directory doesn't necessarily trigger it, but once it > > > starts, it appears to do it for the same directory ??? I'm not sure if > > > I've ever seem it happening to two different directories at the same > > > time ??? > > > > > > Also, please note that the du command is run from the physical > > > server, as root ??? > > > > > >> rick > > >> ps: If it is still up and hasn't been rebooted, you could: > > >> sysctl debug.kdb.break_to_debugger=3D1 > > >> - then type at the console and do the following > > >> from the debugger > > >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbo= ok/kerneldebug-deadlocks.html > > >> How well this work depends on what options your kernel was built > > >> with. > > > > > > My remote console on that one doesn't work very well ??? I can view, > > > but I can't type ??? > > > > > > > >=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" --nk8TfLPx+OTa8gAE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIbBAEBAgAGBQJRG/fxAAoJEJDCuSvBvK1B2UEP900T6fi2b5piJ0L56tvYkmVk xc8UeWip1JFCoEoHwe1BNh26QlDJ3QXHwKSzBtlg14+U+v2Q3wI5d90w8/7mOZj9 JfICggaXhzR6by/Ob8v109kKyfK3vFQOB3k7leyX2ZscXnO9D+1o+cfuWezmAtF4 pDxQrajkBIRb3cAVsB8JxwMJCQo0wiSlziE8QZh1qU6k5PzrjmxEgOtFZxLKBCSj lFyFdPb2QCUV4FdoNOYPYlpX9cHOXlmwOwuZFkBSUqrTdyI8USoQ4q/XeAbc0k9N 50w734CIR5wHQAvnsnfw2vVPnB1KAB5RknSxmzsGMmmZQIbOItu1X7JrVxD9kh1C KqK25mfJm3D16/qLvkv4pq0Iwpfypb8jutDltKbNdngaTFLyeuF3IY7w9opxFtCd FjrvtRL2kOJEDP2mAHoTPL9t/gJrLX57EqpJIxZvYawqiORtal3YCi6JcgaE9ElU 3ZbB157KuhJvxf6YPfConIBdWKtMKUgclyuYBELqgFDIVnl4SnU+3wpJD0ADea7/ 0GIwWKHjpd+PNdRbOaeeLg7leJIdzqxET8Sk+hO+L4eNx/1mZjIxaDnYpyOosJ4B E+rr02qXsvO3ztZJ6QUWMJSMFpArbZODEunMBcl/On776/hPIyWPbSkmrHlymB3X 5lEGVBr4m7vHtJabc6E= =bBcd -----END PGP SIGNATURE----- --nk8TfLPx+OTa8gAE-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 21:57:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 30C04E05; Wed, 13 Feb 2013 21:57:42 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from zoom.lafn.org (zoom.lafn.org [108.92.93.123]) by mx1.freebsd.org (Postfix) with ESMTP id E6DAD1F6; Wed, 13 Feb 2013 21:57:41 +0000 (UTC) Received: from [10.0.1.2] (static-71-177-216-148.lsanca.fios.verizon.net [71.177.216.148]) (authenticated bits=0) by zoom.lafn.org (8.14.3/8.14.2) with ESMTP id r1DLvcnB061711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Feb 2013 13:57:40 -0800 (PST) (envelope-from bc979@lafn.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Unusual TCP/IP Packet Size From: Doug Hardie In-Reply-To: <511B6B21.5030606@rdtc.ru> Date: Wed, 13 Feb 2013 13:57:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <796949D9-C945-478F-BF63-A5C0BC0CF6A9@lafn.org> References: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org> <511B6B21.5030606@rdtc.ru> To: Eugene Grosbein X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.97 at zoom.lafn.org X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org, yongari@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, 13 Feb 2013 21:57:42 -0000 On 13 February 2013, at 02:29, Eugene Grosbein = wrote: > 13.02.2013 17:25, Doug Hardie =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has = the following interface: >>=20 >> msk0: flags=3D8843 metric 0 = mtu 1500 >> = options=3Dc011b >> ether 00:11:2f:2a:c7:03 >> inet 10.0.1.199 netmask 0xffffff00 broadcast 10.0.1.255 >> inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1=20 >> nd6 options=3D29 >> media: Ethernet autoselect (100baseTX = ) >> status: active >>=20 >>=20 >> It sent the following packet: (data content abbreviated) >>=20 >> 02:14:42.081617 IP 10.0.1.199.443 > 10.0.1.2.61258: Flags [P.], seq = 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr = 920110183], length 3946 >> 0x0000: 4500 0f9e ea89 4000 4006 2a08 0a00 01c7 = E.....@.@.*..... >> 0x0010: 0a00 0102 01bb ef4a ece1 680b ae37 1bbc = .......J..h..7.. >> 0x0020: 8018 0410 3407 0000 0101 080a 17f3 8ff8 = ....4...=E2=80=A6=E2=80=A6. >>=20 >>=20 >> The indicated packet length is 3946 and the load of data shown is = that size. The MTU on both interfaces is 1500. The receiving system = received 3 packets. There is a router and switch between them. One of = them fragmented that packet. This is part of a SSL/TLS exchange and one = side or the other is hanging on this and just dropping the connection. = I suspect the packet size is the issue. ssldump complains about the = packet too and stops monitoring. Could this possibly be related to the = hardware checksums? >=20 > You have TSO enabled on the interface, so large outgoing TCP packet is = pretty normal. > It will be split by the NIC. Disable TSO with ifconfig if it = interferes with your ssldump. Thanks. Now all the packets are 1500 or under. They all are received = with a SSL header. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 22: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]) by hub.freebsd.org (Postfix) with ESMTP id D8471F2B for ; Wed, 13 Feb 2013 22:01:34 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id B44D0222 for ; Wed, 13 Feb 2013 22:01:34 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta01.emeryville.ca.mail.comcast.net with comcast id zsjL1k00P17UAYkA1y1ZKe; Wed, 13 Feb 2013 22:01:33 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta13.emeryville.ca.mail.comcast.net with comcast id zy1Y1k0091t3BNj8Zy1YG0; Wed, 13 Feb 2013 22:01:33 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2288F73A1C; Wed, 13 Feb 2013 14:01:32 -0800 (PST) Date: Wed, 13 Feb 2013 14:01:32 -0800 From: Jeremy Chadwick To: Doug Hardie Subject: Re: Unusual TCP/IP Packet Size Message-ID: <20130213220132.GA68113@icarus.home.lan> References: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org> <511B6B21.5030606@rdtc.ru> <796949D9-C945-478F-BF63-A5C0BC0CF6A9@lafn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <796949D9-C945-478F-BF63-A5C0BC0CF6A9@lafn.org> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360792893; bh=F7+90MTFgxqEbTFtPWji/NGJloowvC5E1cVI86K8gFI=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=JEWb8/7PuL8c+nWWCRGHNNIkomvfs80LFeYtxiZ/P+aEzMi7IAyM9lLn/yYY7zSLl e3a65pKvx/3LaEnT0O8MHz5bfzpiQLWK86u43RJ9YYs4RSqY/JBAU+/+Nk5hZXZ2TH enlhgMXizamV0I8jr6pDxEZ/TBRsDhoGmmEg4z0GliQAApEpdSEr2jmd4qzFMt12Mt mWOG/gCtK/nlYr5rbpNn68jzDRI4hegXEgMjaBf6JLB2kMZz7M+Zmi2EJZ2LenIiqU Xgiag4M35qNZlFLhg/S5dwLLSDqrdaqrW4K+Bqu/cpypUCxLTg62skxwgPT44ioMCm TBNcTC54V4cTQ== Cc: freebsd-stable@freebsd.org, Eugene Grosbein , yongari@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, 13 Feb 2013 22:01:35 -0000 On Wed, Feb 13, 2013 at 01:57:38PM -0800, Doug Hardie wrote: > > On 13 February 2013, at 02:29, Eugene Grosbein wrote: > > > 13.02.2013 17:25, Doug Hardie ??????????: > >> Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has the following interface: > >> > >> msk0: flags=8843 metric 0 mtu 1500 > >> options=c011b > >> ether 00:11:2f:2a:c7:03 > >> inet 10.0.1.199 netmask 0xffffff00 broadcast 10.0.1.255 > >> inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1 > >> nd6 options=29 > >> media: Ethernet autoselect (100baseTX ) > >> status: active > >> > >> > >> It sent the following packet: (data content abbreviated) > >> > >> 02:14:42.081617 IP 10.0.1.199.443 > 10.0.1.2.61258: Flags [P.], seq 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr 920110183], length 3946 > >> 0x0000: 4500 0f9e ea89 4000 4006 2a08 0a00 01c7 E.....@.@.*..... > >> 0x0010: 0a00 0102 01bb ef4a ece1 680b ae37 1bbc .......J..h..7.. > >> 0x0020: 8018 0410 3407 0000 0101 080a 17f3 8ff8 ....4...??????. > >> > >> > >> The indicated packet length is 3946 and the load of data shown is that size. The MTU on both interfaces is 1500. The receiving system received 3 packets. There is a router and switch between them. One of them fragmented that packet. This is part of a SSL/TLS exchange and one side or the other is hanging on this and just dropping the connection. I suspect the packet size is the issue. ssldump complains about the packet too and stops monitoring. Could this possibly be related to the hardware checksums? > > > > You have TSO enabled on the interface, so large outgoing TCP packet is pretty normal. > > It will be split by the NIC. Disable TSO with ifconfig if it interferes with your ssldump. > > Thanks. Now all the packets are 1500 or under. They all are received with a SSL header. If disabling TSO on msk(4) fixed the issue of the remote end dropping/ignoring the packet, that sounds like a bug in msk(4). Yong-Hyeon, do you have any recent msk(4) patches relating to TSO? -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 22:50:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2C011D2B; Wed, 13 Feb 2013 22:50:22 +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 2DC6A3CA; Wed, 13 Feb 2013 22:50:20 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAF0XHFGDaFvO/2dsb2JhbAA7CoZPujZzgh8BAQEDAQEBASAEJyALBRYOChEZAgQlAQkmBggHBAEIFASHawYMrSySKI06BgqDJ4ETA4hmhi+EXIIzgR2PNoMkT4EFNQ X-IronPort-AV: E=Sophos;i="4.84,660,1355115600"; d="bz2'66?scan'66,208,66";a="16528385" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 13 Feb 2013 17:50:13 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id EBCDDB4054; Wed, 13 Feb 2013 17:50:13 -0500 (EST) Date: Wed, 13 Feb 2013 17:50:13 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Message-ID: <431606432.2998831.1360795813954.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20130213203042.GW2522@kib.kiev.ua> Subject: Re: 9-STABLE -> NFS -> NetAPP: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2998830_1069103783.1360795813952" X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Marc Fournier , Kostik Belousov , freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 22:50:22 -0000 ------=_Part_2998830_1069103783.1360795813952 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Konstantin Belousov wrote: > On Tue, Feb 12, 2013 at 08:50:39PM -0500, Rick Macklem wrote: > > Marc Fournier wrote: > > > Just reset server, so any further details will have to be 'next > > > time' > > > ??? but, just did a csup and am rebuilding ??? the following three > > > files > > > were modified since last build: > > > > > > grep nfs /tmp/output > > > Edit src/sys/fs/nfs/nfs_commonsubs.c > > > Edit src/sys/fs/nfsclient/nfs_clrpcops.c > > > Edit src/sys/fs/nfsserver/nfs_nfsdserv.c > > > > > > > > > On 2013-02-10, at 4:56 PM, Marc Fournier wrote: > > > > > > > > > > > On 2013-02-10, at 4:31 PM, Rick Macklem > > > > wrote: > > > > > > > >> Marc Fournier wrote: > > > >>> Hi John ??? > > > >>> > > > >>> Does this help? > > > >>> > > > >>> root@io:~ # ps auxl | grep du > > > >>> root 1054 0.0 0.1 16176 6600 ?? D 3:15AM 0:05.38 du -skx > > > >>> /vm/2799 > > > >>> 0 > > > >>> 81426 0 20 0 newnfs > > > >>> root 12353 0.0 0.1 16176 5104 ?? D Sat03AM 0:05.41 du -skx > > > >>> /vm/2799 0 > > > >>> 91597 0 20 0 newnfs > > > >>> root 64529 0.0 0.1 16176 5164 ?? D Fri03AM 0:05.40 du -skx > > > >>> /vm/2799 0 > > > >>> 43227 0 20 0 newnfs > > > >>> root 12855 0.0 0.0 16308 1988 0 S+ 5:26AM 0:00.00 grep du 0 > > > >>> 12847 > > > >>> 0 20 > > > >>> 0 piperd > > > >> It is probably too late, but all the lines (without the | grep > > > >> du) > > > >> would be > > > >> more useful. I also include the "H" flag, so it lists threads > > > >> as > > > >> well as > > > >> processes. The above just says the "du" command is waiting for > > > >> a > > > >> vnode lock. > > > >> The interesting process/thread is the one that is holding a > > > >> vnode > > > >> lock > > > >> while waiting for something else. > > > > > > > > As requested, 'ps auxlH' attached ??? > > > > > > > > > > > > > > > > > > Well, I took a look at the ps output and I didn't see anything that > > would > > identify what the hang is. There are a lot of processes sleeping on > > "newnfs" > > (waiting for a vnode lock) and many sleeping on "vofflock" (waiting > > for the > > f_offset lock). > I never got any attachments on the thread. > I got it resent from him. I've attached it to this post, just in case you are interested in taking a look at it. > See > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > for the description of what is needed to start debugging. I already pointed this out (thanks to your previous email thread), but apparently he can't run a console, so I don't know if there is another way to do the same things? > > > > Unfortunately, I can't spot any process/thread that is blocked on > > something > > else, where it would seem likely to be holding either an nfs vnode > > lock or > > f_offset lock that isn't one of these. > > > > There were changes about 5 months ago which it appears fixed a > > deadlock race > > between vnode locks and offset locks for paging (r236321 and > > friends). > No, I do not think that the description of the changes is right. > He does get the odd error reported by nfs_getpages() and I don't think we've isolated why yet. The error is 13 (EACCES), but jhb@ thought it might be because of the bug he fixed where the krpc reported EACCES for the EINTR case. I don't think we've heard back from Marc w.r.t. whether he has gotten any more of these erros logged since applying jhb@'s patch and whether or not the errno has changed to EINTR? I'll admit I don't understand when the VOP_GETPAGES() path gets called vs the vn_io_fault() one. I plan on taking a closer look at the VOP_GETPAGES() call path and see if I can spot any locking issue. > > > > I am wondering if there could be other similar races, possibly > > specific to > > paging in over NFS? (I can't see any case where there is a LOR, so I > > can't > > think of what it might be?) > > > > If you just want the hangs to go away, I'd suggest moving the > > executable > > is /usr/local/sbin (httpd maybe) to a local file system on the > > server, > > since it does seem to be related to paging this executable in over > > NFS. > > > > rick > > ps: I've added kib@ to the cc, in case he is aware of other related > > races? > > > > > >> > > > >> Are you still getting the: > > > >> nfs_getpages: error 13 > > > >> vm_fault: pager read error, pid 11355 (https) > > > > > > > > Fairly quiet: > > > > > > > > > > > > > > > > And that is it since last reboot ~20 days ago ??? > > > > > > > >> > > > >> messages logged? > > > >> > > > >> With John's recent patch, the error# would no longer be 13 if > > > >> it > > > >> was > > > >> caused by the "intr" flag resulting in a Read RPC terminating > > > >> with > > > >> EINTR. > > > >> If you are still getting the above with "error 13", it suggests > > > >> that > > > >> the server is replying EACCES for the Read RPC. > > > >> I suggested before that you check to make sure that the > > > >> executable > > > >> had > > > >> read access for everyone one the file server. Since I didn't > > > >> hear > > > >> back, > > > >> I'll assume this is the case. > > > > > > > > Don't understand this question ??? I have 34 VPSs running off of I was just asking if you have seen any of the nfs_getpages errors logged since applying jhb@'s patch and whether or not the errno in it has changed from 13 to something else? > > > > this > > > > server right now ??? that 'du process' runs against each of > > > > those VPSs > > > > every night, and this problem started happening on Friday > > > > night's > > > > run ??? ~18 days into uptime ??? so the same process has run > > > > repeatedly, > > > > with no issues, 18 times before it hung on Friday ??? also, the > > > > hang, > > > > once 'triggered', only seems to recur against the same directory > > > > ??? > > > > the same directory doesn't necessarily trigger it, but once it > > > > starts, it appears to do it for the same directory ??? I'm not > > > > sure if > > > > I've ever seem it happening to two different directories at the > > > > same > > > > time ??? > > > > > > > > Also, please note that the du command is run from the physical > > > > server, as root ??? > > > > > > > >> rick > > > >> ps: If it is still up and hasn't been rebooted, you could: > > > >> sysctl debug.kdb.break_to_debugger=1 > > > >> - then type at the console and do the > > > >> following > > > >> from the debugger > > > >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > > >> How well this work depends on what options your kernel was > > > >> built > > > >> with. > > > > > > > > My remote console on that one doesn't work very well ??? I can > > > > view, > > > > but I can't type ??? > > > > Unfortunately, I don't know how to do this unless you are in the kernel DB. rick > > > > > > > > > > _______________________________________________ > > > 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" ------=_Part_2998830_1069103783.1360795813952-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 23:14:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 14A235FD; Wed, 13 Feb 2013 23:14:48 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id C591A6E1; Wed, 13 Feb 2013 23:14:47 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.188]) by hub.org (Postfix) with ESMTP id 013051BB1AB4; Wed, 13 Feb 2013 19:14:40 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.188]) (amavisd-maia, port 10024) with ESMTP id 47660-08; Wed, 13 Feb 2013 23:14:39 +0000 (UTC) Received: from [10.5.250.150] (remote.ilcs.sd63.bc.ca [142.31.148.2]) by hub.org (Postfix) with ESMTPA id D39011BB1AB3; Wed, 13 Feb 2013 19:14:38 -0400 (AST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 9-STABLE -> NFS -> NetAPP: From: "Marc G. Fournier" In-Reply-To: <431606432.2998831.1360795813954.JavaMail.root@erie.cs.uoguelph.ca> Date: Wed, 13 Feb 2013 15:14:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <431606432.2998831.1360795813954.JavaMail.root@erie.cs.uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1499) Cc: Konstantin Belousov , Kostik Belousov , freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:14:48 -0000 On 2013-02-13, at 14:50 , Rick Macklem wrote: > He does get the odd error reported by nfs_getpages() and I don't > think we've isolated why yet. The error is 13 (EACCES), but jhb@ > thought it might be because of the bug he fixed where the krpc > reported EACCES for the EINTR case. I don't think we've heard > back from Marc w.r.t. whether he has gotten any more of these > erros logged since applying jhb@'s patch and whether or not > the errno has changed to EINTR? As mentioned previously, it doesn't happen all that often =85 this = latest one was after 21 days of uptime (or so) =85 I just upgraded the = kernel on that machine to take into consideration changes to hfs *since* = the last upgrade, so it might be another 20-30 days before it happens = again *if* that last patch didn't' fix it =85 I have several servers that do have fully operational remote consoles = though =85 to save time if/when it happens next, what do I all need to = run? ps auxlH procstat -kk (for which process? =85 all part of that "group", or = just one of the apparently hung processes?) sysctl debug.kdb.break_to_debugger=3D1 (shell) (from console) now, is there a way of forcing it to do a dump core so that I can run = the various commands from a shell *after* its rebooted? Not = particularly easy to redirect console output to a file (or is it?), so = anything that scrolls off the screen is pretty much lost =85 I'm using a = DRAC card in most cases, no serial consoles or anything like that that I = can run within a script session =85 a 'ps' listing is >500 lines long, = just to give an idea ... From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 23:16:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7230D719; Wed, 13 Feb 2013 23:16:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 01311702; Wed, 13 Feb 2013 23:16:30 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1DNGJBE073050; Thu, 14 Feb 2013 01:16:19 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1DNGJBE073050 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1DNGHEl073049; Thu, 14 Feb 2013 01:16:17 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Feb 2013 01:16:17 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: 9-STABLE -> NFS -> NetAPP: Message-ID: <20130213231617.GZ2522@kib.kiev.ua> References: <20130213203042.GW2522@kib.kiev.ua> <431606432.2998831.1360795813954.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tQONwxv1SlzjgsUV" Content-Disposition: inline In-Reply-To: <431606432.2998831.1360795813954.JavaMail.root@erie.cs.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: Marc Fournier , freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:16:31 -0000 --tQONwxv1SlzjgsUV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2013 at 05:50:13PM -0500, Rick Macklem wrote: > I got it resent from him. I've attached it to this post, just in case you > are interested in taking a look at it. I do not see the voffset wchains surprising. All of them seems to occur in the multithreading process. The usual reason for the voffset blocking is the use of the same file (as in struct file *) to perform operations =66rom several threads in parallel. One thread locked the file offset by using read() or write(), and sleeping waiting for the vnode locked. All other threads performing read or write on the same file, e.g. by using the same file descriptor, are locked on the file offset before even trying to lock the vnode. What I see interesting in the output you mailed, is the pid 93636. Note that several its threads are in the 'T' state. It means stopped, while other threads obviously do file i/o due to vofflock state. I wonder if some stopped thread owns nfs vnode lock. It could be some omission in the handling of PBDRY/TDF_BDRY, or other bug. It is absolutely impossible to say anything definitive without proper diagnostic. At least the procstat -kk is needed. --tQONwxv1SlzjgsUV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRHB7BAAoJEJDCuSvBvK1BWYQP/0ghBV9Ab0FpZB2v6k1cZ0WW JLsgFcdkn/YpPkiLDhifDDmCA3S1YX/AnlvIHEA61LgHtIvF8yMhkBpk8Ph0gYhF UAyCe3UlZTOtSMF/ZXp3IBvNvGrTyAN90qxYwZDMGB9NbmucTCMOeWgiE18VrLwa kbsHkvyVcbOTIj/ucR/nZg5Tnlp9pr9Dt1h7fEHXS2SdNnMTKwROTk9RoQA2Z7Zt XQoxF+aLHKHD8d3itzSTAZ53zSplo5mwnGuucKB9A8AjZph32j3AtbCPcfVYE/Kj ZGkbSAqlkCkCLa3+21um19cJWENPz8537z60P9YnyVi6HQroSfjTDUFoWOoVeq95 ZAD8dnlRNDdDV9bhHGvInPuwEjWWnavCy1tyfl8q3YsJyZnVLQM5cCA0/VbSgthI Q9dGgNjSxmnJRVRtFlkun7Tg+3RijXptyCGdtxvnMtP/FVoyBsrDffOohdnhDhZT n23sN9EVRm+jW48koSsZYtqaR0Ek7iEMUqLgX77bHDefKhCYWMl2ydYA1cd5F54L krLepKqV5w2Dxo+csyRWzveLTkzUpPhXl2pR7QeL3T4DDD5yfvkADOrWbjVvsVpl 3etTJ3ZlAfPX+AQEay7+NOEc9XJA/Ra8IKI98s47MdktgKWX5km65bpP8JIDjDCq bzdt3DqK3J/yHmeP7Xy1 =DIyu -----END PGP SIGNATURE----- --tQONwxv1SlzjgsUV-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 23:46:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BAF21306; Wed, 13 Feb 2013 23:46:30 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 8138A846; Wed, 13 Feb 2013 23:46:30 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.189]) by hub.org (Postfix) with ESMTP id B3F7F1BB1AB4; Wed, 13 Feb 2013 19:46:29 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.189]) (amavisd-maia, port 10024) with ESMTP id 33829-03; Wed, 13 Feb 2013 23:46:29 +0000 (UTC) Received: from [10.5.250.150] (remote.ilcs.sd63.bc.ca [142.31.148.2]) by hub.org (Postfix) with ESMTPA id 9AED81BB1AB3; Wed, 13 Feb 2013 19:46:28 -0400 (AST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 9-STABLE -> NFS -> NetAPP: From: "Marc G. Fournier" In-Reply-To: <20130213231617.GZ2522@kib.kiev.ua> Date: Wed, 13 Feb 2013 15:46:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0AFE2DC0-A6C9-44D4-BEA4-C0223C25CBD8@hub.org> References: <20130213203042.GW2522@kib.kiev.ua> <431606432.2998831.1360795813954.JavaMail.root@erie.cs.uoguelph.ca> <20130213231617.GZ2522@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1499) Cc: Rick Macklem , freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:46:30 -0000 On 2013-02-13, at 15:16 , Konstantin Belousov = wrote: > On Wed, Feb 13, 2013 at 05:50:13PM -0500, Rick Macklem wrote: >> I got it resent from him. I've attached it to this post, just in case = you >> are interested in taking a look at it. >=20 > I do not see the voffset wchains surprising. All of them seems to = occur > in the multithreading process. The usual reason for the voffset = blocking > is the use of the same file (as in struct file *) to perform = operations > from several threads in parallel. One thread locked the file offset = by > using read() or write(), and sleeping waiting for the vnode locked. > All other threads performing read or write on the same file, e.g. by > using the same file descriptor, are locked on the file offset before > even trying to lock the vnode. >=20 > What I see interesting in the output you mailed, is the pid 93636. = Note > that several its threads are in the 'T' state. It means stopped, while > other threads obviously do file i/o due to vofflock state. I wonder if > some stopped thread owns nfs vnode lock. It could be some omission in = the > handling of PBDRY/TDF_BDRY, or other bug. >=20 > It is absolutely impossible to say anything definitive without proper > diagnostic. At least the procstat -kk is needed. I had sent out the output of procstat -kk at the time =85 for next time, = would you need procstat against all of the 'duplicate processes' that = aren't' killable? for instance, in this case, there were three du = commands running doing the same thing,none of which were killable =85 so = procstat -kk for all three of those? From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 23:54:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7F2A2610; Wed, 13 Feb 2013 23:54:30 +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 159108A5; Wed, 13 Feb 2013 23:54:29 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAAcnHFGDaFvO/2dsb2JhbABFhk+6NnOCHwEBAQMBAQEBIAQnIAsFFhgCAg0ZAikBCSYGCAcEAQgUBIdrBgytOJIygSOMJw2DGoETA4hmiwuCM4EdjzaDJE9+Bxce X-IronPort-AV: E=Sophos;i="4.84,660,1355115600"; d="scan'208";a="13936263" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 13 Feb 2013 18:54:28 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 1FE67B4048; Wed, 13 Feb 2013 18:54:28 -0500 (EST) Date: Wed, 13 Feb 2013 18:54:28 -0500 (EST) From: Rick Macklem To: "Marc G. Fournier" Message-ID: <426187631.3000937.1360799668107.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: 9-STABLE -> NFS -> NetAPP: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Konstantin Belousov , freebsd-stable@freebsd.org, Kostik Belousov , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:54:30 -0000 Marc Fournier wrote: > On 2013-02-13, at 14:50 , Rick Macklem wrote: >=20 > > He does get the odd error reported by nfs_getpages() and I don't > > think we've isolated why yet. The error is 13 (EACCES), but jhb@ > > thought it might be because of the bug he fixed where the krpc > > reported EACCES for the EINTR case. I don't think we've heard > > back from Marc w.r.t. whether he has gotten any more of these > > erros logged since applying jhb@'s patch and whether or not > > the errno has changed to EINTR? >=20 > As mentioned previously, it doesn't happen all that often =E2=80=A6 this > latest one was after 21 days of uptime (or so) =E2=80=A6 I just upgraded = the > kernel on that machine to take into consideration changes to hfs > *since* the last upgrade, so it might be another 20-30 days before it > happens again *if* that last patch didn't' fix it =E2=80=A6 >=20 > I have several servers that do have fully operational remote consoles > though =E2=80=A6 to save time if/when it happens next, what do I all need= to > run? >=20 > ps auxlH > procstat -kk (for which process? =E2=80=A6 all part of that "group"= , or > just one of the apparently hung processes?) The pid that is in "T" state for the "ps auxlH". > sysctl debug.kdb.break_to_debugger=3D1 (shell) > (from console) >=20 Then the commands described in: http://www.freebsd.org/doc/en_US.ISO8859-1/book/developers-handbook/kerneld= ebug-deadlocks.html "show alllocks" and "show lockedvnods" may be the most useful, I think you can also "show sleepchain " "show lockchain " using the that is in "T" state. If you haven't built your kernel with "options WITNESS", this won't work we= ll. > now, is there a way of forcing it to do a dump core so that I can run > the various commands from a shell *after* its rebooted? No idea. Someone familiar with what you can do to core dump and how to get your system to make will have to answer this. > Not > particularly easy to redirect console output to a file (or is it?), so > anything that scrolls off the screen is pretty much lost =E2=80=A6 I'm us= ing a > DRAC card in most cases, no serial consoles or anything like that that > I can run within a script session =E2=80=A6 a 'ps' listing is >500 lines = long, > just to give an idea ... >=20 >=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" From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 23:56:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DCB87723; Wed, 13 Feb 2013 23:56:11 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-gg0-x22a.google.com (gg-in-x022a.1e100.net [IPv6:2607:f8b0:4002:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 94FFF8C6; Wed, 13 Feb 2013 23:56:11 +0000 (UTC) Received: by mail-gg0-f170.google.com with SMTP id k4so1070841ggn.15 for ; Wed, 13 Feb 2013 15:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8e8mltNubW/B+LUoVjPCK4RMyhDEQfY3n9KjTnF6f20=; b=ZaudNftGe69dJBJqtkNnrL/jgUxVZxLZsFTTZSNiDvYvz9ubxwVZCsO7TrYuLU3F57 301M+V9CJ/lG95HvZAvHcJT0K8dcXeUQg9LxX3M4xlWz+uTP3G6phhH7QY+DRpHpmulB Hx9KVACmpfzNvFu2irUrrbbLF8cOOy1FA/OlpncNu10DcHtVgC2DnIL1rZhufS0+eygs CRGES4sg7U5N4oN0udzET1R62O1MFpBWZRcZbBR1dC7bgGujBjKzD8hBc1kQNPcDvNCt E6+vTewppHBVOYQM57+UQbrcYQtYhpIlMKspp9/27C3WxCTrYUKn7LTFm8ywa8uYoFHP XZ6Q== MIME-Version: 1.0 X-Received: by 10.236.128.116 with SMTP id e80mr29072180yhi.111.1360799766750; Wed, 13 Feb 2013 15:56:06 -0800 (PST) Sender: tomek.cedro@gmail.com Received: by 10.49.71.204 with HTTP; Wed, 13 Feb 2013 15:56:06 -0800 (PST) In-Reply-To: <201302131048.06370.jhb@freebsd.org> References: <201302111606.06731.jhb@freebsd.org> <201302131048.06370.jhb@freebsd.org> Date: Thu, 14 Feb 2013 00:56:06 +0100 X-Google-Sender-Auth: 6Nz21BeVlNGfvUnQkuPMHnrX-F8 Message-ID: Subject: Re: 9.1-RELEASE AMD64 crash under VBox 4.2.6 when IO APIC is disabled From: CeDeROM To: John Baldwin 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: Wed, 13 Feb 2013 23:56:11 -0000 On Wed, Feb 13, 2013 at 4:48 PM, John Baldwin wrote: >> The simple answer that I have deduced is that APIC is MANDATORY for >> AMD64 machines and they won't run otherwise? This is why generic AMD64 >> install fails when no APIC is enabled in the VBox? > > No, it is not quite like that. x86 machines have two entirely different > sets of interrupt controllers. (...) Hello John :-) Things now are more clear to me, thank you for your extensive explanation!! :-) I am wondering in that case if it wouldn't be a good idea to put atpci (old x86 IRQ handler) in the GENERIC configuration, or at least in the default installer kernel, so it is a safe fallback for a AMD64 machines with no APIC support, as for example VBox with APIC disabled..? Is atpic removed on purpose so it enforces use of new APIC and so better performance? Thank you! :-) Tomek Cedro -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 01:23:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C86647AF; Thu, 14 Feb 2013 01:23:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-da0-f41.google.com (mail-da0-f41.google.com [209.85.210.41]) by mx1.freebsd.org (Postfix) with ESMTP id 7BCFBBFC; Thu, 14 Feb 2013 01:23:49 +0000 (UTC) Received: by mail-da0-f41.google.com with SMTP id e20so839288dak.0 for ; Wed, 13 Feb 2013 17:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=+xscmwQkbocDgBUqwTzZuK4bG0dFWJ5F+Pq6AcFh9AQ=; b=mbALlj/H0wWhDybLaC9xPGA8Trm2wanS8gf9UXkZvJQPzc0M/F6MvwaqPzbdpiFckb LNyEIRLa3B1t3BrvTHig4yZUs5u0hgjcu7k3vDa9svsNMouX1+GjBX587M10lI3D1lcE dYsdE0kXPjm3bYeJZ3F25vfgmnSFHkQqH1jfgh+k9cKnlnJhvyLNRXbaDj3mIcNbj8l2 q3rXLhozMhKBa+R3+tJb5VhKo7gM93hKEoZJE551ulsraLQTs5vq5+MxsOLi69QSQKKM nf6mHcRbr6YMx+rFqPaOIfFF58SQyL6lSP9zh7U7GVIIr2VxSpN52g+5vHyOWoBI5iWO Vz8A== X-Received: by 10.66.82.163 with SMTP id j3mr69729290pay.31.1360805028753; Wed, 13 Feb 2013 17:23:48 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id f9sm87611929paz.12.2013.02.13.17.23.44 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 13 Feb 2013 17:23:47 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 14 Feb 2013 10:23:39 +0900 From: YongHyeon PYUN Date: Thu, 14 Feb 2013 10:23:39 +0900 To: Jeremy Chadwick Subject: Re: Unusual TCP/IP Packet Size Message-ID: <20130214012339.GA2945@michelle.cdnetworks.com> References: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org> <511B6B21.5030606@rdtc.ru> <796949D9-C945-478F-BF63-A5C0BC0CF6A9@lafn.org> <20130213220132.GA68113@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130213220132.GA68113@icarus.home.lan> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, Eugene Grosbein , yongari@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 01:23:49 -0000 On Wed, Feb 13, 2013 at 02:01:32PM -0800, Jeremy Chadwick wrote: > On Wed, Feb 13, 2013 at 01:57:38PM -0800, Doug Hardie wrote: > > > > On 13 February 2013, at 02:29, Eugene Grosbein wrote: > > > > > 13.02.2013 17:25, Doug Hardie ??????????: > > >> Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has the following interface: > > >> > > >> msk0: flags=8843 metric 0 mtu 1500 > > >> options=c011b > > >> ether 00:11:2f:2a:c7:03 > > >> inet 10.0.1.199 netmask 0xffffff00 broadcast 10.0.1.255 > > >> inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1 > > >> nd6 options=29 > > >> media: Ethernet autoselect (100baseTX ) > > >> status: active > > >> > > >> > > >> It sent the following packet: (data content abbreviated) > > >> > > >> 02:14:42.081617 IP 10.0.1.199.443 > 10.0.1.2.61258: Flags [P.], seq 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr 920110183], length 3946 > > >> 0x0000: 4500 0f9e ea89 4000 4006 2a08 0a00 01c7 E.....@.@.*..... > > >> 0x0010: 0a00 0102 01bb ef4a ece1 680b ae37 1bbc .......J..h..7.. > > >> 0x0020: 8018 0410 3407 0000 0101 080a 17f3 8ff8 ....4...??????. > > >> > > >> > > >> The indicated packet length is 3946 and the load of data shown is that size. The MTU on both interfaces is 1500. The receiving system received 3 packets. There is a router and switch between them. One of them fragmented that packet. This is part of a SSL/TLS exchange and one side or the other is hanging on this and just dropping the connection. I suspect the packet size is the issue. ssldump complains about the packet too and stops monitoring. Could this possibly be related to the hardware checksums? > > > > > > You have TSO enabled on the interface, so large outgoing TCP packet is pretty normal. > > > It will be split by the NIC. Disable TSO with ifconfig if it interferes with your ssldump. > > > > Thanks. Now all the packets are 1500 or under. They all are received with a SSL header. > > If disabling TSO on msk(4) fixed the issue of the remote end > dropping/ignoring the packet, that sounds like a bug in msk(4). > > Yong-Hyeon, do you have any recent msk(4) patches relating to TSO? No, I'm not aware of msk(4) related TSO issues. For some controllers, msk(4) used to touch reserved registers which in turn resulted in unexpected results. This was fixed long time ago but it would be good idea to cold-boot the box and see whether that makes any difference. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 01:37: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]) by hub.freebsd.org (Postfix) with ESMTP id B8589CB5; Thu, 14 Feb 2013 01:37:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-da0-f45.google.com (mail-da0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id 882ABCFD; Thu, 14 Feb 2013 01:37:38 +0000 (UTC) Received: by mail-da0-f45.google.com with SMTP id w4so847664dam.32 for ; Wed, 13 Feb 2013 17:37:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=eA6TvlS+UVIIZ/tWOahJSTvOhqRSmm4BRS8bDNpqZMw=; b=0Q8tB1xvsZhfT9Mea5qpgphFDw7TZ9brPP0vgBn0BM+GCev60bW3VFElxZMoh50xBE JKlo5TCzpygR5ZOdvagCxg835sdcRkAYbgiovb1A2cO4GFasQbpHAd4f1+cmbdpR+Yq9 /suMP/rsmeAYLn9/GUNl1oWKMFdqA+OYwqpc7UFvUGlibwkgtYE5IY6xSwZhz2JE4Qi0 LRbbtZbMKX+39wZc93WJz0dOHaridvE0cDSm2N1nELsmioTX5B02mO5KKVf1c+czZvIK saoIkS5fBug8yveBqBAfiL+99IsVMHuZCzPY6WhOQpqviJNu2XcAI0jgCTadBcpRfDN0 1sIg== X-Received: by 10.66.83.196 with SMTP id s4mr69522547pay.74.1360805852493; Wed, 13 Feb 2013 17:37:32 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id o1sm10740631pax.2.2013.02.13.17.37.28 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 13 Feb 2013 17:37:31 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 14 Feb 2013 10:37:23 +0900 From: YongHyeon PYUN Date: Thu, 14 Feb 2013 10:37:23 +0900 To: Jeremy Chadwick Subject: Re: Unusual TCP/IP Packet Size Message-ID: <20130214013723.GB2945@michelle.cdnetworks.com> References: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org> <511B6B21.5030606@rdtc.ru> <20130213130059.GA57337@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130213130059.GA57337@icarus.home.lan> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, Eugene Grosbein , yongari@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 01:37:38 -0000 On Wed, Feb 13, 2013 at 05:00:59AM -0800, Jeremy Chadwick wrote: > On Wed, Feb 13, 2013 at 05:29:53PM +0700, Eugene Grosbein wrote: > > 13.02.2013 17:25, Doug Hardie ??????????: > > > Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has the following interface: > > > > > > msk0: flags=8843 metric 0 mtu 1500 > > > options=c011b > > > ether 00:11:2f:2a:c7:03 > > > inet 10.0.1.199 netmask 0xffffff00 broadcast 10.0.1.255 > > > inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1 > > > nd6 options=29 > > > media: Ethernet autoselect (100baseTX ) > > > status: active > > > > > > > > > It sent the following packet: (data content abbreviated) > > > > > > 02:14:42.081617 IP 10.0.1.199.443 > 10.0.1.2.61258: Flags [P.], seq 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr 920110183], length 3946 > > > 0x0000: 4500 0f9e ea89 4000 4006 2a08 0a00 01c7 E.....@.@.*..... > > > 0x0010: 0a00 0102 01bb ef4a ece1 680b ae37 1bbc .......J..h..7.. > > > 0x0020: 8018 0410 3407 0000 0101 080a 17f3 8ff8 ....4...??????. > > > > > > > > > The indicated packet length is 3946 and the load of data shown is that size. The MTU on both interfaces is 1500. The receiving system received 3 packets. There is a router and switch between them. One of them fragmented that packet. This is part of a SSL/TLS exchange and one side or the other is hanging on this and just dropping the connection. I suspect the packet size is the issue. ssldump complains about the packet too and stops monitoring. Could this possibly be related to the hardware checksums? > > > > You have TSO enabled on the interface, so large outgoing TCP packet is pretty normal. > > It will be split by the NIC. Disable TSO with ifconfig if it interferes with your ssldump. > > This is not the behaviour I see with em(4) on a 82573E with all defaults > used (which includes TSO4). Note that Doug is using msk(4). > > I can provide packet captures on both ends of a LAN segment using both > tcpdump (on the FreeBSD side) and Wireshark (on the Windows side) that > show a difference in behaviour compared to what Doug sees. This is strange. tcpdump sees a (big) TCP segment right before controller actually transmits it. So if TSO is active for the TCP segment, you should see a series of small TCP packets on receiver side(i.e. 3 TCP packets in Doug's case). If you don't see a big TCP segment with tcpdump on TX path, probably TSO was not used for the TCP segment. It's possible for controller to corrupt the TCP segment during segmentation but Doug's tcpdump looks completely normal to me since tcpdump sees the segment before TCP segmentation. > > What I see on the FreeBSD side with tcpdump is repeated "bad-len 0" > messages for payloads which are chunked or segmented as a result of TSO. > I do not see a 1:1 ratio of "bad-len" entries to chunked payloads; I > only see one "bad-len" entry for all chunks (up until the next ACK or > PSH+ACK of course). > I vaguely recall that some users reported similar TSO issues on various drivers. The root cause of the issue was not identified though. Personally I couldn't reproduce the issue at that time. It could be a driver or network stack bug. > The important part: I do not see captured TCP packets reporting a length > greater than MTU (or MSS for that matter (remember: IP header + TCP > header + MSS <= MTU). > > Also note for Doug: remember that if you're doing packet captures > between two devices that have NAT involved, you may see different > behaviour. Example case: > > 03:58:47.907582 IP 67.180.84.87.2983 > 206.125.172.42.80: Flags [.], ack 13419, win 64240, length 0 > 03:58:47.907649 IP 206.125.172.42.80 > 67.180.84.87.2983: Flags [.], seq 17799:19259, ack 292, win 1026, length 1460 > 03:58:47.907679 IP 206.125.172.42.80 > 67.180.84.87.2983: Flags [.], seq 19259:20719, ack 292, win 1026, length 1460 > 03:58:47.912546 IP 67.180.84.87.2983 > 206.125.172.42.80: Flags [.], ack 16339, win 64240, length 0 > > In the above example there's a Linux NAT router (67.180.84.87) with a > client (192.168.1.50) behind it, talking to 206.125.172.42. MTU is 1500 > (I obviously didn't include the initial SYN :-) ). > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Mountain View, CA, US | > | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 02:14:07 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BAD152D2 for ; Thu, 14 Feb 2013 02:14:07 +0000 (UTC) (envelope-from pierre@guinoiseau.eu) Received: from mail.poildetroll.net (tritus.poildetroll.net [IPv6:2a01:4f8:160:72a3::6:1]) by mx1.freebsd.org (Postfix) with ESMTP id 6AB48E16 for ; Thu, 14 Feb 2013 02:14:07 +0000 (UTC) Received: from tritus.poildetroll.net (tritus.poildetroll.net [IPv6:2a01:4f8:160:72a3::6:1]) by mail.poildetroll.net (Postfix) with ESMTP id 9E90DA8D6; Thu, 14 Feb 2013 03:13:58 +0100 (CET) X-Virus-Scanned: amavisd-new at poildetroll.net Received: from mail.poildetroll.net ([IPv6:2a01:4f8:160:72a3::6:1]) by tritus.poildetroll.net (mail.poildetroll.net [IPv6:2a01:4f8:160:72a3::6:1]) (amavisd-new, port 10024) with LMTP id xTnvutzGcpfj; Thu, 14 Feb 2013 03:13:57 +0100 (CET) Received: from kyleck.poildetroll.net (kyleck.poildetroll.net [IPv6:2a01:4f8:160:72a3::7:1]) by mail.poildetroll.net (Postfix) with SMTP id 7129CA8CE; Thu, 14 Feb 2013 03:13:57 +0100 (CET) Date: Thu, 14 Feb 2013 03:13:57 +0100 From: Pierre Guinoiseau To: Adam McDougall , Kai Gallasch Subject: Re: FreeBSD 9.1 - openldap slapd lockups, mutex problems Message-ID: <20130214021356.GJ46275@kyleck.poildetroll.net> References: <50FEB684.9040201@egr.msu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j+MD90OnwjQyWNYt" Content-Disposition: inline In-Reply-To: <50FEB684.9040201@egr.msu.edu> X-Operating-System: FreeBSD 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: Thu, 14 Feb 2013 02:14:07 -0000 --j+MD90OnwjQyWNYt Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 22/01/2013 10:55:48, Adam McDougall wrote: > On 01/22/13 05:19, Kai Gallasch wrote: > > Hi. > > > > (Im am sending this to the "stable" list, because it maybe kernel relat= ed.. ) > > > > On 9.1-RELEASE I am witnessing lockups of the openldap slapd daemon. > > > > The slapd runs for some days and then hangs, consuming high amounts of = CPU. > > In this state slapd can only be restarted by SIGKILL. > > > > # procstat -kk 71195 > > PID TID COMM TDNAME KSTACK > > 71195 149271 slapd - mi_switch+0x186 sleepq_c= atch_signals+0x2cc sleepq_wait_sig+0x16 _sleep+0x29d do_wait+0x678 __umtx_o= p_wait+0x68 amd64_syscall+0x546 Xfast_syscall+0xf7 >=20 > > On UFS2 slapd runs fine, without showing the error. > > Has anyone else running openldap-server on FreeBSD 9.1 inside a jail se= en similar problems? >=20 > I have seen openldap spin the cpu and even run out of memory to get=20 > killed on some of our test systems running ~9.1-rel with zfs. No jails. > I'm not sure what would have put load on our test systems other than=20 > nightly scripts. I had to focus my attention on other servers so I=20 > don't have one to inspect at this point, but I won't be surprised if I=20 > see this in production. Thanks for the tip about it being ZFS related,= =20 > and I'll let you know if I find anything out. This is mostly a "me too"= =20 > reply. Hi, I've the same problem too, inside a jail, stored on ZFS. I've tried various tuning in slapd.conf, but none fixed the problem. While hanging, db_stat -c shows that all locks are being used, I've tried to set the limit really hig= h, far more than normally needed, but it didn't help. I may have the same prob= lem with amavisd-new but I've to verify that to be sure the symptoms are simila= r. I had no problem at all with the same setup on FreeBSD 8.2R, it was my most stable service back then. I've not tried with 9.0R. --j+MD90OnwjQyWNYt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEcSGQACgkQJikNJSAyef+Z5gCgyDvHdqwdX2GuQETp2IYqic6t sRMAmwRq1l3sCIo128AaPMh9ogYp3s4Z =pViJ -----END PGP SIGNATURE----- --j+MD90OnwjQyWNYt-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 05:10: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]) by hub.freebsd.org (Postfix) with ESMTP id 440F2830; Thu, 14 Feb 2013 05:10:38 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by mx1.freebsd.org (Postfix) with ESMTP id 1A9A9648; Thu, 14 Feb 2013 05:10:37 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id bg4so1144210pad.40 for ; Wed, 13 Feb 2013 21:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=L/EdWVFJ8sRbCS/Jib2kKuVEju7L2bk/D3RoN4088gA=; b=ZkFCfAkM8XdlyyUy5kOzNTmQex4x7gcDpdyHriw9GTlA4vQFHDC7dYDAQcOFKOtgjr qA4YhJa8V8zLlSj/OhAHEbrVSbHDd61kpIism2ncwGUrcaF1mny0eUJbuyjjYy0NpmNX DQBNBMBlgJAoZsYVOPaarjr1awE8+yCLdvEcTIUYiDwMnIqGLsRL5YCXVlUmWpP0qQpJ NzF4d7gH7Cap9qSig0sinrm9Jvx5pr3xO83BcFEAv71yewJ/xO+MGFkdrT/iRvwSin4P SyVPqciXB1Xkr1KvMhaucKTYRiLNaFwmLJRYER1DOQdtzWT/xQ5DC5tVHWyJYmjeOz2U wqNA== MIME-Version: 1.0 X-Received: by 10.68.255.161 with SMTP id ar1mr257916pbd.17.1360818637115; Wed, 13 Feb 2013 21:10:37 -0800 (PST) Received: by 10.67.2.65 with HTTP; Wed, 13 Feb 2013 21:10:36 -0800 (PST) In-Reply-To: <20130214013723.GB2945@michelle.cdnetworks.com> References: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org> <511B6B21.5030606@rdtc.ru> <20130213130059.GA57337@icarus.home.lan> <20130214013723.GB2945@michelle.cdnetworks.com> Date: Wed, 13 Feb 2013 21:10:36 -0800 Message-ID: Subject: Re: Unusual TCP/IP Packet Size From: Kevin Oberman To: pyunyh@gmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jeremy Chadwick , freebsd-stable@freebsd.org, Eugene Grosbein , yongari@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, 14 Feb 2013 05:10:38 -0000 On Wed, Feb 13, 2013 at 5:37 PM, YongHyeon PYUN wrote: > On Wed, Feb 13, 2013 at 05:00:59AM -0800, Jeremy Chadwick wrote: >> On Wed, Feb 13, 2013 at 05:29:53PM +0700, Eugene Grosbein wrote: >> > 13.02.2013 17:25, Doug Hardie ??????????: >> > > Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has t= he following interface: >> > > >> > > msk0: flags=3D8843 metric 0 = mtu 1500 >> > > options=3Dc011b >> > > ether 00:11:2f:2a:c7:03 >> > > inet 10.0.1.199 netmask 0xffffff00 broadcast 10.0.1.255 >> > > inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1 >> > > nd6 options=3D29 >> > > media: Ethernet autoselect (100baseTX ) >> > > status: active >> > > >> > > >> > > It sent the following packet: (data content abbreviated) >> > > >> > > 02:14:42.081617 IP 10.0.1.199.443 > 10.0.1.2.61258: Flags [P.], seq = 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr 92011018= 3], length 3946 >> > > 0x0000: 4500 0f9e ea89 4000 4006 2a08 0a00 01c7 E.....@.@.*..... >> > > 0x0010: 0a00 0102 01bb ef4a ece1 680b ae37 1bbc .......J..h..7.. >> > > 0x0020: 8018 0410 3407 0000 0101 080a 17f3 8ff8 ....4...??????. >> > > >> > > >> > > The indicated packet length is 3946 and the load of data shown is th= at size. The MTU on both interfaces is 1500. The receiving system receive= d 3 packets. There is a router and switch between them. One of them fragm= ented that packet. This is part of a SSL/TLS exchange and one side or the o= ther is hanging on this and just dropping the connection. I suspect the pa= cket size is the issue. ssldump complains about the packet too and stops mo= nitoring. Could this possibly be related to the hardware checksums? >> > >> > You have TSO enabled on the interface, so large outgoing TCP packet is= pretty normal. >> > It will be split by the NIC. Disable TSO with ifconfig if it interfere= s with your ssldump. >> >> This is not the behaviour I see with em(4) on a 82573E with all defaults >> used (which includes TSO4). Note that Doug is using msk(4). >> >> I can provide packet captures on both ends of a LAN segment using both >> tcpdump (on the FreeBSD side) and Wireshark (on the Windows side) that >> show a difference in behaviour compared to what Doug sees. > > This is strange. tcpdump sees a (big) TCP segment right before > controller actually transmits it. So if TSO is active for the TCP > segment, you should see a series of small TCP packets on receiver > side(i.e. 3 TCP packets in Doug's case). If you don't see a big TCP > segment with tcpdump on TX path, probably TSO was not used for the > TCP segment. > It's possible for controller to corrupt the TCP segment during > segmentation but Doug's tcpdump looks completely normal to me since > tcpdump sees the segment before TCP segmentation. > >> >> What I see on the FreeBSD side with tcpdump is repeated "bad-len 0" >> messages for payloads which are chunked or segmented as a result of TSO. >> I do not see a 1:1 ratio of "bad-len" entries to chunked payloads; I >> only see one "bad-len" entry for all chunks (up until the next ACK or >> PSH+ACK of course). >> > > I vaguely recall that some users reported similar TSO issues on > various drivers. The root cause of the issue was not identified > though. Personally I couldn't reproduce the issue at that time. > It could be a driver or network stack bug. Beware TSO. It can significantly improve throughput on high speed networks, but it really has issues. TSO segments the data and transmits all of them back-to-back with no delay beyond IFG (the 802.3 mandated space between frames) TSO does not understand congestion control. If there is congestion and TSO sends several frames in a row, it is entirely possible that a queue is full or getting close enough to full to start dropping packets and these segmented frames are excellent candidates. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 05:26:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D46089C0; Thu, 14 Feb 2013 05:26:32 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 654446AD; Thu, 14 Feb 2013 05:26:32 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.188]) by hub.org (Postfix) with ESMTP id 817E726089F; Thu, 14 Feb 2013 01:26:31 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.188]) (amavisd-maia, port 10024) with ESMTP id 19413-09; Thu, 14 Feb 2013 05:26:30 +0000 (UTC) Received: from [192.168.0.52] (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id 5F92426089E; Thu, 14 Feb 2013 01:26:29 -0400 (AST) Content-Type: multipart/mixed; boundary="Apple-Mail=_FC784159-3DF1-4F73-AD85-CF032170EB07" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 9-STABLE -> NFS -> NetAPP: From: Marc Fournier In-Reply-To: <426187631.3000937.1360799668107.JavaMail.root@erie.cs.uoguelph.ca> Date: Wed, 13 Feb 2013 21:26:27 -0800 Message-Id: <9A149E78-BB4F-414D-AAE5-331C5934FF82@hub.org> References: <426187631.3000937.1360799668107.JavaMail.root@erie.cs.uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1499) X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , freebsd-stable@freebsd.org, Kostik Belousov , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 05:26:32 -0000 --Apple-Mail=_FC784159-3DF1-4F73-AD85-CF032170EB07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2013-02-13, at 3:54 PM, Rick Macklem wrote: >>=20 > The pid that is in "T" state for the "ps auxlH". Different server, last kernel update on Jan 22nd, https process this = time instead of du last time. I've attached: ps auxlH=20 ps auxlH of just the processes that are in TJ state (6 httpd servers) procstat output for each of the 6 process --Apple-Mail=_FC784159-3DF1-4F73-AD85-CF032170EB07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 They are included as attachments =85 if these don't make it through, let = me know, just figured I'd try and keep it compact ... =20 --Apple-Mail=_FC784159-3DF1-4F73-AD85-CF032170EB07-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 05:31:10 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 82017B11; Thu, 14 Feb 2013 05:31:10 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 2A7476DA; Thu, 14 Feb 2013 05:31:10 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.188]) by hub.org (Postfix) with ESMTP id EEBA226089F; Thu, 14 Feb 2013 01:31:08 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.188]) (amavisd-maia, port 10024) with ESMTP id 26828-02; Thu, 14 Feb 2013 05:31:07 +0000 (UTC) Received: from [192.168.0.52] (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id EFC7D26089E; Thu, 14 Feb 2013 01:31:05 -0400 (AST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 9-STABLE -> NFS -> NetAPP: From: Marc Fournier In-Reply-To: <9A149E78-BB4F-414D-AAE5-331C5934FF82@hub.org> Date: Wed, 13 Feb 2013 21:31:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <426187631.3000937.1360799668107.JavaMail.root@erie.cs.uoguelph.ca> <9A149E78-BB4F-414D-AAE5-331C5934FF82@hub.org> To: Rick Macklem X-Mailer: Apple Mail (2.1499) Cc: Konstantin Belousov , freebsd-stable@freebsd.org, Kostik Belousov , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 05:31:10 -0000 Note that checking the console, there are no errors pertaining to this = on it =85=20 On 2013-02-13, at 9:26 PM, Marc Fournier wrote: >=20 > On 2013-02-13, at 3:54 PM, Rick Macklem wrote: >=20 >>>=20 >> The pid that is in "T" state for the "ps auxlH". >=20 > Different server, last kernel update on Jan 22nd, https process this = time instead of du last time. >=20 > I've attached: >=20 > ps auxlH=20 > ps auxlH of just the processes that are in TJ state (6 httpd = servers) > procstat output for each of the 6 process >=20 > >=20 > They are included as attachments =85 if these don't make it through, = let me know, just figured I'd try and keep it compact ... =20 >=20 >=20 >=20 >=20 From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 06:52:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C0018709; Thu, 14 Feb 2013 06:52:29 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by mx1.freebsd.org (Postfix) with ESMTP id 96163927; Thu, 14 Feb 2013 06:52:29 +0000 (UTC) Received: by mail-pb0-f46.google.com with SMTP id uo15so46687pbc.33 for ; Wed, 13 Feb 2013 22:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=35hg9rfcgv3/CnaJe3hwlR6768HbbbZJCaReZFe1s4w=; b=woX7c7RfmowlqDXwgqTHh4TWyThUnRVd4/oFmmKWqBgUe9yNYpTqwRSvonJol6l+mE yd2LcPPL8ETDOJcjVvRdLuu0aHb1WNLJVQ8c9YDluB7oicW2IRbMZG2D/zKahJdmk1Em uRYtB8gZFTq7GttjZRChAhPkTlTsWNxaS4pSb9Erqae8c1FFQXp2U+j35xPTkH3dBjqB Wi12J6/CaVRFrjVAJVk9QEhZ1rZzd3TCJ1O9TkR0S6ODZDy7ArFhG7EvtY1xyVB+ZrAf CU/ov+OsM9Lozo6aTUqDLbEma2iuh9yMaK/5UdvyUMOP9ybeUkuny20REA1QRLa9war7 bFqA== X-Received: by 10.68.232.69 with SMTP id tm5mr915215pbc.150.1360824329997; Wed, 13 Feb 2013 22:45:29 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id az3sm355948pbd.23.2013.02.13.22.45.25 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 13 Feb 2013 22:45:28 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 14 Feb 2013 15:45:21 +0900 From: YongHyeon PYUN Date: Thu, 14 Feb 2013 15:45:21 +0900 To: Kevin Oberman Subject: Re: Unusual TCP/IP Packet Size Message-ID: <20130214064521.GA1464@michelle.cdnetworks.com> References: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org> <511B6B21.5030606@rdtc.ru> <20130213130059.GA57337@icarus.home.lan> <20130214013723.GB2945@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Jeremy Chadwick , freebsd-stable@freebsd.org, Eugene Grosbein , yongari@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 06:52:29 -0000 On Wed, Feb 13, 2013 at 09:10:36PM -0800, Kevin Oberman wrote: > On Wed, Feb 13, 2013 at 5:37 PM, YongHyeon PYUN wrote: > > On Wed, Feb 13, 2013 at 05:00:59AM -0800, Jeremy Chadwick wrote: > >> On Wed, Feb 13, 2013 at 05:29:53PM +0700, Eugene Grosbein wrote: > >> > 13.02.2013 17:25, Doug Hardie ??????????: > >> > > Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has the following interface: > >> > > > >> > > msk0: flags=8843 metric 0 mtu 1500 > >> > > options=c011b > >> > > ether 00:11:2f:2a:c7:03 > >> > > inet 10.0.1.199 netmask 0xffffff00 broadcast 10.0.1.255 > >> > > inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1 > >> > > nd6 options=29 > >> > > media: Ethernet autoselect (100baseTX ) > >> > > status: active > >> > > > >> > > > >> > > It sent the following packet: (data content abbreviated) > >> > > > >> > > 02:14:42.081617 IP 10.0.1.199.443 > 10.0.1.2.61258: Flags [P.], seq 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr 920110183], length 3946 > >> > > 0x0000: 4500 0f9e ea89 4000 4006 2a08 0a00 01c7 E.....@.@.*..... > >> > > 0x0010: 0a00 0102 01bb ef4a ece1 680b ae37 1bbc .......J..h..7.. > >> > > 0x0020: 8018 0410 3407 0000 0101 080a 17f3 8ff8 ....4...??????. > >> > > > >> > > > >> > > The indicated packet length is 3946 and the load of data shown is that size. The MTU on both interfaces is 1500. The receiving system received 3 packets. There is a router and switch between them. One of them fragmented that packet. This is part of a SSL/TLS exchange and one side or the other is hanging on this and just dropping the connection. I suspect the packet size is the issue. ssldump complains about the packet too and stops monitoring. Could this possibly be related to the hardware checksums? > >> > > >> > You have TSO enabled on the interface, so large outgoing TCP packet is pretty normal. > >> > It will be split by the NIC. Disable TSO with ifconfig if it interferes with your ssldump. > >> > >> This is not the behaviour I see with em(4) on a 82573E with all defaults > >> used (which includes TSO4). Note that Doug is using msk(4). > >> > >> I can provide packet captures on both ends of a LAN segment using both > >> tcpdump (on the FreeBSD side) and Wireshark (on the Windows side) that > >> show a difference in behaviour compared to what Doug sees. > > > > This is strange. tcpdump sees a (big) TCP segment right before > > controller actually transmits it. So if TSO is active for the TCP > > segment, you should see a series of small TCP packets on receiver > > side(i.e. 3 TCP packets in Doug's case). If you don't see a big TCP > > segment with tcpdump on TX path, probably TSO was not used for the > > TCP segment. > > It's possible for controller to corrupt the TCP segment during > > segmentation but Doug's tcpdump looks completely normal to me since > > tcpdump sees the segment before TCP segmentation. > > > >> > >> What I see on the FreeBSD side with tcpdump is repeated "bad-len 0" > >> messages for payloads which are chunked or segmented as a result of TSO. > >> I do not see a 1:1 ratio of "bad-len" entries to chunked payloads; I > >> only see one "bad-len" entry for all chunks (up until the next ACK or > >> PSH+ACK of course). > >> > > > > I vaguely recall that some users reported similar TSO issues on > > various drivers. The root cause of the issue was not identified > > though. Personally I couldn't reproduce the issue at that time. > > It could be a driver or network stack bug. > > Beware TSO. It can significantly improve throughput on high speed > networks, but it really has issues. > > TSO segments the data and transmits all of them back-to-back with no > delay beyond IFG (the 802.3 mandated space between frames) TSO does > not understand congestion control. If there is congestion and TSO > sends several frames in a row, it is entirely possible that a queue is > full or getting close enough to full to start dropping packets and > these segmented frames are excellent candidates. I'm not saying the drawback of TSO. Sometimes segmented packets have malformed IP header length under certain circumstances such that these packets were dropped on receiver side. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 07:06:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A1A5B8F4; Thu, 14 Feb 2013 07:06:27 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 58F539A1; Thu, 14 Feb 2013 07:06:27 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.188]) by hub.org (Postfix) with ESMTP id 6950619719C1; Thu, 14 Feb 2013 03:06:26 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.188]) (amavisd-maia, port 10024) with ESMTP id 66223-08; Thu, 14 Feb 2013 07:06:25 +0000 (UTC) Received: from [192.168.0.52] (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id 0703919719C0; Thu, 14 Feb 2013 03:06:23 -0400 (AST) Content-Type: multipart/mixed; boundary="Apple-Mail=_C9904FF1-8F86-44C0-B56A-D1CDB49AC78E" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 9-STABLE -> NFS -> NetAPP: From: Marc Fournier In-Reply-To: Date: Wed, 13 Feb 2013 23:06:22 -0800 Message-Id: References: <426187631.3000937.1360799668107.JavaMail.root@erie.cs.uoguelph.ca> <9A149E78-BB4F-414D-AAE5-331C5934FF82@hub.org> To: Rick Macklem X-Mailer: Apple Mail (2.1499) X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , freebsd-stable@freebsd.org, Kostik Belousov , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 07:06:27 -0000 --Apple-Mail=_C9904FF1-8F86-44C0-B56A-D1CDB49AC78E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I don't know if this provides any benefit, but I just shut down all the = VPSs on that server, so that all the 'noise' is removed from the ps = listing, which I've attached =85=20 --Apple-Mail=_C9904FF1-8F86-44C0-B56A-D1CDB49AC78E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 2013-02-13, at 9:31 PM, Marc Fournier wrote: >=20 > Note that checking the console, there are no errors pertaining to this = on it =85=20 >=20 >=20 > On 2013-02-13, at 9:26 PM, Marc Fournier wrote: >=20 >>=20 >> On 2013-02-13, at 3:54 PM, Rick Macklem wrote: >>=20 >>>>=20 >>> The pid that is in "T" state for the "ps auxlH". >>=20 >> Different server, last kernel update on Jan 22nd, https process this = time instead of du last time. >>=20 >> I've attached: >>=20 >> ps auxlH=20 >> ps auxlH of just the processes that are in TJ state (6 httpd = servers) >> procstat output for each of the 6 process >>=20 >> >>=20 >> They are included as attachments =85 if these don't make it through, = let me know, just figured I'd try and keep it compact ... =20 >>=20 >>=20 >>=20 >>=20 >=20 --Apple-Mail=_C9904FF1-8F86-44C0-B56A-D1CDB49AC78E-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 07:54:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 280BC472; Thu, 14 Feb 2013 07:54:27 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from zoom.lafn.org (zoom.lafn.org [108.92.93.123]) by mx1.freebsd.org (Postfix) with ESMTP id D9EE4B5C; Thu, 14 Feb 2013 07:54:26 +0000 (UTC) Received: from [10.0.1.2] (static-71-177-216-148.lsanca.fios.verizon.net [71.177.216.148]) (authenticated bits=0) by zoom.lafn.org (8.14.3/8.14.2) with ESMTP id r1E7sOY5076211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Feb 2013 23:54:25 -0800 (PST) (envelope-from bc979@lafn.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Unusual TCP/IP Packet Size From: Doug Hardie In-Reply-To: <20130214064521.GA1464@michelle.cdnetworks.com> Date: Wed, 13 Feb 2013 23:54:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3BB4EC29-0FD5-4F5D-9189-51770E2B55D5@lafn.org> References: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org> <511B6B21.5030606@rdtc.ru> <20130213130059.GA57337@icarus.home.lan> <20130214013723.GB2945@michelle.cdnetworks.com> <20130214064521.GA1464@michelle.cdnetworks.com> To: pyunyh@gmail.com X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.97 at zoom.lafn.org X-Virus-Status: Clean Cc: Jeremy Chadwick , freebsd-stable@freebsd.org, Eugene Grosbein , yongari@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, 14 Feb 2013 07:54:27 -0000 On 13 February 2013, at 22:45, YongHyeon PYUN wrote: > On Wed, Feb 13, 2013 at 09:10:36PM -0800, Kevin Oberman wrote: >> On Wed, Feb 13, 2013 at 5:37 PM, YongHyeon PYUN = wrote: >>> On Wed, Feb 13, 2013 at 05:00:59AM -0800, Jeremy Chadwick wrote: >>>> On Wed, Feb 13, 2013 at 05:29:53PM +0700, Eugene Grosbein wrote: >>>>> 13.02.2013 17:25, Doug Hardie ??????????: >>>>>> Monitoring a tcpdump between two systems, a FreeBSD 9.1 system = has the following interface: >>>>>>=20 >>>>>> msk0: flags=3D8843 metric = 0 mtu 1500 >>>>>> = options=3Dc011b >>>>>> ether 00:11:2f:2a:c7:03 >>>>>> inet 10.0.1.199 netmask 0xffffff00 broadcast 10.0.1.255 >>>>>> inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1 >>>>>> nd6 options=3D29 >>>>>> media: Ethernet autoselect (100baseTX = ) >>>>>> status: active >>>>>>=20 >>>>>>=20 >>>>>> It sent the following packet: (data content abbreviated) >>>>>>=20 >>>>>> 02:14:42.081617 IP 10.0.1.199.443 > 10.0.1.2.61258: Flags [P.], = seq 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr = 920110183], length 3946 >>>>>> 0x0000: 4500 0f9e ea89 4000 4006 2a08 0a00 01c7 = E.....@.@.*..... >>>>>> 0x0010: 0a00 0102 01bb ef4a ece1 680b ae37 1bbc = .......J..h..7.. >>>>>> 0x0020: 8018 0410 3407 0000 0101 080a 17f3 8ff8 = ....4...??????. >>>>>>=20 >>>>>>=20 >>>>>> The indicated packet length is 3946 and the load of data shown is = that size. The MTU on both interfaces is 1500. The receiving system = received 3 packets. There is a router and switch between them. One of = them fragmented that packet. This is part of a SSL/TLS exchange and one = side or the other is hanging on this and just dropping the connection. = I suspect the packet size is the issue. ssldump complains about the = packet too and stops monitoring. Could this possibly be related to the = hardware checksums? >>>>>=20 >>>>> You have TSO enabled on the interface, so large outgoing TCP = packet is pretty normal. >>>>> It will be split by the NIC. Disable TSO with ifconfig if it = interferes with your ssldump. >>>>=20 >>>> This is not the behaviour I see with em(4) on a 82573E with all = defaults >>>> used (which includes TSO4). Note that Doug is using msk(4). >>>>=20 >>>> I can provide packet captures on both ends of a LAN segment using = both >>>> tcpdump (on the FreeBSD side) and Wireshark (on the Windows side) = that >>>> show a difference in behaviour compared to what Doug sees. >>>=20 >>> This is strange. tcpdump sees a (big) TCP segment right before >>> controller actually transmits it. So if TSO is active for the TCP >>> segment, you should see a series of small TCP packets on receiver >>> side(i.e. 3 TCP packets in Doug's case). If you don't see a big TCP >>> segment with tcpdump on TX path, probably TSO was not used for the >>> TCP segment. >>> It's possible for controller to corrupt the TCP segment during >>> segmentation but Doug's tcpdump looks completely normal to me since >>> tcpdump sees the segment before TCP segmentation. >>>=20 >>>>=20 >>>> What I see on the FreeBSD side with tcpdump is repeated "bad-len 0" >>>> messages for payloads which are chunked or segmented as a result of = TSO. >>>> I do not see a 1:1 ratio of "bad-len" entries to chunked payloads; = I >>>> only see one "bad-len" entry for all chunks (up until the next ACK = or >>>> PSH+ACK of course). >>>>=20 >>>=20 >>> I vaguely recall that some users reported similar TSO issues on >>> various drivers. The root cause of the issue was not identified >>> though. Personally I couldn't reproduce the issue at that time. >>> It could be a driver or network stack bug. >>=20 >> Beware TSO. It can significantly improve throughput on high speed >> networks, but it really has issues. >>=20 >> TSO segments the data and transmits all of them back-to-back with no >> delay beyond IFG (the 802.3 mandated space between frames) TSO does >> not understand congestion control. If there is congestion and TSO >> sends several frames in a row, it is entirely possible that a queue = is >> full or getting close enough to full to start dropping packets and >> these segmented frames are excellent candidates. >=20 > I'm not saying the drawback of TSO. Sometimes segmented packets > have malformed IP header length under certain circumstances such > that these packets were dropped on receiver side. How do I configure the msk0 interface in rc.conf to disable tso4? I can = easily do it with ifconfig, but don't see how to make sure its disabled = after a boot. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 08:17:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 19AFCC75 for ; Thu, 14 Feb 2013 08:17:58 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 45B22D4F for ; Thu, 14 Feb 2013 08:17:56 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r1E8Ho8s003387; Thu, 14 Feb 2013 15:17:50 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <511C9DA9.30502@rdtc.ru> Date: Thu, 14 Feb 2013 15:17:45 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Doug Hardie Subject: Re: Unusual TCP/IP Packet Size References: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org> <511B6B21.5030606@rdtc.ru> <20130213130059.GA57337@icarus.home.lan> <20130214013723.GB2945@michelle.cdnetworks.com> <20130214064521.GA1464@michelle.cdnetworks.com> <3BB4EC29-0FD5-4F5D-9189-51770E2B55D5@lafn.org> In-Reply-To: <3BB4EC29-0FD5-4F5D-9189-51770E2B55D5@lafn.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit 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, 14 Feb 2013 08:17:58 -0000 14.02.2013 14:54, Doug Hardie ÐÉÛÅÔ: > > How do I configure the msk0 interface in rc.conf to disable tso4? I can easily do it with ifconfig, but don't see how to make sure its disabled after a boot. Just add corresponding flag to ifconfig_msk0 line in rc.conf: ifconfig_msk0="inet 10.0.1.199 netmask 0xffffff00 -tso -vlanhwtso" From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 09:19:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DE6B2B9A for ; Thu, 14 Feb 2013 09:19:50 +0000 (UTC) (envelope-from prvs=07574758ac=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9A92BFB5 for ; Thu, 14 Feb 2013 09:19:50 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U5uyn-000F6w-CS for freebsd-stable@freebsd.org; Thu, 14 Feb 2013 10:19:45 +0100 Date: Thu, 14 Feb 2013 10:19:45 +0100 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.1 - openldap slapd lockups, mutex problems Message-ID: <20130214091945.GZ38901@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org References: <50FEB684.9040201@egr.msu.edu> <20130214021356.GJ46275@kyleck.poildetroll.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <20130214021356.GJ46275@kyleck.poildetroll.net> X-Face: "TT~P'b_)-jKU_0^a=usXryz`YTz)z.[FZrI,A~PREI2U}frrZ`>_J&; ^t|^.dR/mqtC,Vb.Y>~u8(|aL)vAv(k">zY"]*m*y|b8S7:WK[/qP5i>HO#Ek; C[X:b|FP0*Ly_4Ni User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Oliver Brandmueller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 09:19:50 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Feb 14, 2013 at 03:13:57AM +0100, Pierre Guinoiseau wrote: > > I have seen openldap spin the cpu and even run out of memory to get=20 > > killed on some of our test systems running ~9.1-rel with zfs. [...] > I've the same problem too, inside a jail, stored on ZFS. I've tried vario= us > tuning in slapd.conf, but none fixed the problem. While hanging, db_stat = -c > shows that all locks are being used, I've tried to set the limit really h= igh, > far more than normally needed, but it didn't help. I may have the same pr= oblem > with amavisd-new but I've to verify that to be sure the symptoms are simi= lar. I have amd64 9.1-STABLE r245456 (about Jan 15) running. I have openldap=20 openldap-server-2.4.33_2 running, depending on libltdl-2.4.2 and=20 db46-4.6.21.4 . The system is zfs only (for the local filesystems, where openldap is=20 running - it has several NFS mounts for other purposes though). It's up=20 and running for about a month now (29 days) and never showed any=20 problematic behaviour regarding to slapd. I have ~10 SEARCH requests per seconds avg and only minor=20 ADD/MODIFY/DELETE operations. It has several binds und unbinds, about=20 1/10th of the requests. It runs in slurpd slave mode for my master LDAP. zroot/var/db runs with compression=3Doff, dedup=3Doff, zroot is a mirrored= =20 pool on 2 Intel SATA SSD drives inside a GPT partition. Swap is on a ZFS=20 zvol. - Oliver --=20 | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEcrDEACgkQiqtMdzjafynbhQCfWJTEf3+87ImP3I/EyhRWSXKR 5ZEAnivCDpKCN4MjGl7xNNbIbq2es3mY =d86z -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 11:04:14 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4F010892 for ; Thu, 14 Feb 2013 11:04:14 +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 0FB05912 for ; Thu, 14 Feb 2013 11:04:13 +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 A23C77E92D for ; Thu, 14 Feb 2013 12:04:04 +0100 (CET) Message-ID: <511CC4A4.1090604@bsdforen.de> Date: Thu, 14 Feb 2013 12:04:04 +0100 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130129 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: stable/9 Xorg freezes and hangs in drmlk2 References: <51178A7C.9000700@bsdforen.de> In-Reply-To: <51178A7C.9000700@bsdforen.de> X-Enigmail-Version: 1.4.6 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: Thu, 14 Feb 2013 11:04:14 -0000 On 10/02/2013 12:54, Dominic Fandrey wrote: > Occasionally Xorg freezes and hangs in state drmlk2, when I start > the compositing manager or an overlay window (i.e. mplayer) opens. > > The last time that happened (starting the compositor) I ssh'ed into > the box and collected some data. … It happened again, this time when I tried to play back a video with mplayer. This time Xorg hung in the state _drmwtq_. Everything looks the same apart from the state: http://pastebin.com/hXVKyjp1 This time however I wasn't able to revive Xorg, so this time I've got an Xorg.0.log full of juicy error output, that I hope may be able to give someone a clue: http://pastebin.com/yTzXyjG7 Uptime ~3d 16h. -- 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 Feb 14 12:34:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1D3DEAC7; Thu, 14 Feb 2013 12:34:53 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 8CD8AECD; Thu, 14 Feb 2013 12:34:51 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id r1ECduCd032966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Feb 2013 13:39:56 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <511CD9DF.4020606@omnilan.de> Date: Thu, 14 Feb 2013 13:34:39 +0100 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-questions@freebsd.org Subject: Why scf (sfcd) monitoring sometimes doesn't work X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5EF6CB1D01F87DB64189ADBF" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Feb 2013 12:34:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5EF6CB1D01F87DB64189ADBF Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, I found fsc (http://www.freshports.org/sysutils/fsc/) to be extremely useful. Unfortunately, I can't get some services to be monitored, "fscadm enable" just failes with "Could not monitor service." I don't know how kqueue interaction is working, so I can't guess why some services can be monitored fine and others not. How can I start finding out what goes wrong? How does the rc-name play into that role? Thanks, -Harry --------------enig5EF6CB1D01F87DB64189ADBF 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) iEYEARECAAYFAlEc2eQACgkQLDqVQ9VXb8haWgCgr4nZ6tGYY+KPGKLuYZpkgeG0 AjgAmgKGN1CKNJUB5kQrvzQep+6GuSkd =wson -----END PGP SIGNATURE----- --------------enig5EF6CB1D01F87DB64189ADBF-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 13:04:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 51397584; Thu, 14 Feb 2013 13:04:50 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id D7B0DEA; Thu, 14 Feb 2013 13:04:49 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id r1EDA0DH033377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Feb 2013 14:10:00 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <511CE0F0.4060408@omnilan.de> Date: Thu, 14 Feb 2013 14:04:48 +0100 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-questions@freebsd.org Subject: Why fsc (fscd) monitoring sometimes doesn't work [Was: Re: Why scf (sfcd) monitoring sometimes doesn't work] References: <511CD9DF.4020606@omnilan.de> In-Reply-To: <511CD9DF.4020606@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2FE602CEFAA149F93133465E" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Feb 2013 13:04:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2FE602CEFAA149F93133465E Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable schrieb Harald Schmalzbauer am 14.02.2013 13:34 (localtime): > Hello, > > I found fsc (http://www.freshports.org/sysutils/fsc/) to be extremely > useful. > Unfortunately, I can't get some services to be monitored, "fscadm > enable" just failes with "Could not monitor service." > I don't know how kqueue interaction is working, so I can't guess why > some services can be monitored fine and others not. > How can I start finding out what goes wrong? > How does the rc-name play into that role? > Sorry for the ugly typo in the topic! --------------enig2FE602CEFAA149F93133465E 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) iEYEARECAAYFAlEc4PAACgkQLDqVQ9VXb8hsaQCfTqFp4T1t6EHPkzOOuXb98qXs t9MAmwSaIyQL/bsg+BgCCTFOeTqPfBn5 =UOcK -----END PGP SIGNATURE----- --------------enig2FE602CEFAA149F93133465E-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 13:55:32 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B0F5686D for ; Thu, 14 Feb 2013 13:55:32 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 526DB365 for ; Thu, 14 Feb 2013 13:55:32 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r1EDtTdH006251 for ; Thu, 14 Feb 2013 20:55:29 +0700 (NOVT) (envelope-from eugen@grosbein.pp.ru) Message-ID: <511CECCC.60400@grosbein.pp.ru> Date: Thu, 14 Feb 2013 20:55:24 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: stable@freebsd.org Subject: i386: vm.pmap kernel local race condition 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, 14 Feb 2013 13:55:32 -0000 Hi! I've got FreeBSD 8.3-STABLE/i386 server that can be reliably panicked using just 'squid -k rotatelog' command. It seems the system suffers from the problem described here: http://cxsecurity.com/issue/WLB-2010090156 I could not find any FreeBSD Security Advisory containing a fix. My server has 4G physical RAM (about 3.2G available) and runs squid (about 110M VSS) with 500 ntlm_auth subprocesses. Lesser number of ntlm_auth sometimes results in squid crash as it sometimes has several hundreds requests per second to authorize and is intolerant to exhaustion of free ntlm_auth. "squid -k rotatelog" at midnight results in crash: Feb 14 00:03:00 irl savecore: reboot after panic: get_pv_entry: increase vm.pmap.shpgperproc Feb 14 00:03:00 irl savecore: writing core to vmcore.1 Btw, I have coredump. vm.pmap.shpgperproc has default value (200) here, as well as m.v_free_min, vm.v_free_reserved, and vm.v_free_target and KVA_PAGES. These crashes are pretty regular # last|fgrep reboot reboot ~ Thu Feb 14 00:03 reboot ~ Wed Feb 13 19:08 reboot ~ Wed Feb 13 10:40 reboot ~ Wed Feb 13 00:04 reboot ~ Tue Feb 12 00:09 reboot ~ Mon Feb 11 00:03 reboot ~ Sun Feb 10 00:03 reboot ~ Thu Feb 7 00:03 reboot ~ Wed Feb 6 10:52 reboot ~ Sun Feb 3 00:03 reboot ~ Sat Feb 2 00:03 May this be considered as security problem? Can it be fixed without switch to amd64? I have only remote access to this production server, no serial console. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 13:57:16 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C01EDB1F; Thu, 14 Feb 2013 13:57:16 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 59C1E3CB; Thu, 14 Feb 2013 13:57:16 +0000 (UTC) Received: from mr16.lnh.mail.rcn.net ([207.172.157.36]) by smtp02.lnh.mail.rcn.net with ESMTP; 14 Feb 2013 08:57:16 -0500 Received: from smtp04.lnh.mail.rcn.net (smtp04.lnh.mail.rcn.net [207.172.157.104]) by mr16.lnh.mail.rcn.net (MOS 4.3.4-GA) with ESMTP id CFY16737; Thu, 14 Feb 2013 08:57:15 -0500 X-Auth-ID: anat Received: from pool-71-187-31-131.nwrknj.fios.verizon.net (HELO [192.168.1.8]) ([71.187.31.131]) by smtp04.lnh.mail.rcn.net with ESMTP; 14 Feb 2013 08:57:14 -0500 Message-ID: <511CED39.2010909@aldan.algebra.com> Date: Thu, 14 Feb 2013 08:57:13 -0500 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130209 Thunderbird/17.0.2 MIME-Version: 1.0 To: stable@freebsd.org Subject: Why can't gcc-4.2.1 build usable libreoffice? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: office@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, 14 Feb 2013 13:57:16 -0000 Hello! I just finished building editors/libreoffice with gcc-4.2.1 -- had to edit the port's Makefile to prevent it from picking a different compiler. Everything built and installed, but libreoffice dies on start-up (right after flashing the splash-window): (gdb) where #0 0x000000080596c1aa in cppu::__getTypeEntries () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #1 0x000000080596c333 in cppu::__queryDeepNoXInterface () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #2 0x000000080596d4a2 in cppu::WeakImplHelper_query () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #3 0x00000008116f2b03 in cppu::WeakImplHelper1::queryInterface () from /opt/lib/libreoffice/ure/lib/bootstrap.uno.so #4 0x0000000805970347 in cppu::OInterfaceContainerHelper::disposeAndClear () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #5 0x00000008059705b2 in cppu::OMultiTypeInterfaceContainerHelper::disposeAndClear () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #6 0x000000080593309f in cppu::OComponentHelper::dispose () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #7 0x0000000805963d00 in cppu::OFactoryComponentHelper::dispose () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #8 0x00000008116ec296 in stoc_smgr::OServiceManager::disposing () from /opt/lib/libreoffice/ure/lib/bootstrap.uno.so #9 0x000000080596af05 in cppu::WeakComponentImplHelperBase::dispose () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #10 0x00000008116e6244 in stoc_smgr::ORegistryServiceManager::dispose () from /opt/lib/libreoffice/ure/lib/bootstrap.uno.so #11 0x000000080596a573 in cppu::WeakComponentImplHelperBase::release () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #12 0x00000008059482f6 in (anonymous namespace)::createTypeRegistry () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #13 0x00000008059487bf in cppu::defaultBootstrap_InitialComponentContext () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #14 0x0000000805948918 in cppu::defaultBootstrap_InitialComponentContext () from /opt/lib/libreoffice/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #15 0x000000080212f883 in desktop::Desktop::InitApplicationServiceManager () from /opt/lib/libreoffice/program/libmergedlo.so #16 0x000000080211f362 in desktop::Desktop::Init () from /opt/lib/libreoffice/program/libmergedlo.so #17 0x0000000807622113 in InitVCL () from /opt/lib/libreoffice/program/libvcllo.so #18 0x0000000807623151 in ImplSVMain () from /opt/lib/libreoffice/program/libvcllo.so #19 0x00000008076232d5 in SVMain () from /opt/lib/libreoffice/program/libvcllo.so #20 0x000000080214942e in soffice_main () from /opt/lib/libreoffice/program/libmergedlo.so #21 0x0000000000400773 in main () I do not blame the office@ team -- the port did not want to use gcc-4.2.1, I forced it to. But I'd like to know, what is wrong with the compiler shipped by FreeBSD-9.1 (and the only one, if WITHOUT_CLANG is defined), that prevents building a healthy libreoffice? Is there a bug fixed in gcc-4.6? Or is it some (incorrect) assumption made by libreoffice code? Thank you, -mi From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 15:55:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 634CBAB9 for ; Thu, 14 Feb 2013 15:55:32 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by mx1.freebsd.org (Postfix) with ESMTP id 3B44DC41 for ; Thu, 14 Feb 2013 15:55:32 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta15.emeryville.ca.mail.comcast.net with comcast id 0EFW1l0051bwxycAFFvY0r; Thu, 14 Feb 2013 15:55:32 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta18.emeryville.ca.mail.comcast.net with comcast id 0FvW1l0131t3BNj8eFvWcd; Thu, 14 Feb 2013 15:55:31 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 90C3973A1C; Thu, 14 Feb 2013 07:55:30 -0800 (PST) Date: Thu, 14 Feb 2013 07:55:30 -0800 From: Jeremy Chadwick To: Doug Hardie Subject: Re: Unusual TCP/IP Packet Size Message-ID: <20130214155530.GA86144@icarus.home.lan> References: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org> <511B6B21.5030606@rdtc.ru> <20130213130059.GA57337@icarus.home.lan> <20130214013723.GB2945@michelle.cdnetworks.com> <20130214064521.GA1464@michelle.cdnetworks.com> <3BB4EC29-0FD5-4F5D-9189-51770E2B55D5@lafn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BB4EC29-0FD5-4F5D-9189-51770E2B55D5@lafn.org> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360857332; bh=U2dQs4gOUs2JIb/nwLKDCFFJBb5T/rOR6ZSxpkzW+Ws=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=mGkx+0HGi1+pxp3IiIluMC5U8e2BUYSqRaWi2KNoVqG3qvN+WybXPRH+hGyHVJ/Fp 9SEhwLiQWoDYhYAotNbwMY1O5/ComtvYHjRMy7/hlusBuwHXxbBqzTtrgBmkKkMTiJ K8kldfs52xL3USXzj6WYsGWstYjuMyUvGkVQG6BxrZNt/2jrQarMSIWfDZdQ3SWOv+ CMrNRZleqPwtP3TYtt/+ttPzawmm7K3rGNwm9RaxUdGyiB9pV5RPISZ62zz5eGS2EV iYXWQVaXLCcV2rouYOzTaUJ3RNwIhIK7ycV/+TXakniJW9YlbZG6qw3E46vL0m6DAZ EZX7ADe506zlg== Cc: pyunyh@gmail.com, freebsd-stable@freebsd.org, Eugene Grosbein , yongari@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, 14 Feb 2013 15:55:32 -0000 On Wed, Feb 13, 2013 at 11:54:24PM -0800, Doug Hardie wrote: > > On 13 February 2013, at 22:45, YongHyeon PYUN wrote: > > > On Wed, Feb 13, 2013 at 09:10:36PM -0800, Kevin Oberman wrote: > >> On Wed, Feb 13, 2013 at 5:37 PM, YongHyeon PYUN wrote: > >>> On Wed, Feb 13, 2013 at 05:00:59AM -0800, Jeremy Chadwick wrote: > >>>> On Wed, Feb 13, 2013 at 05:29:53PM +0700, Eugene Grosbein wrote: > >>>>> 13.02.2013 17:25, Doug Hardie ??????????: > >>>>>> Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has the following interface: > >>>>>> > >>>>>> msk0: flags=8843 metric 0 mtu 1500 > >>>>>> options=c011b > >>>>>> ether 00:11:2f:2a:c7:03 > >>>>>> inet 10.0.1.199 netmask 0xffffff00 broadcast 10.0.1.255 > >>>>>> inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1 > >>>>>> nd6 options=29 > >>>>>> media: Ethernet autoselect (100baseTX ) > >>>>>> status: active > >>>>>> > >>>>>> > >>>>>> It sent the following packet: (data content abbreviated) > >>>>>> > >>>>>> 02:14:42.081617 IP 10.0.1.199.443 > 10.0.1.2.61258: Flags [P.], seq 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr 920110183], length 3946 > >>>>>> 0x0000: 4500 0f9e ea89 4000 4006 2a08 0a00 01c7 E.....@.@.*..... > >>>>>> 0x0010: 0a00 0102 01bb ef4a ece1 680b ae37 1bbc .......J..h..7.. > >>>>>> 0x0020: 8018 0410 3407 0000 0101 080a 17f3 8ff8 ....4...??????. > >>>>>> > >>>>>> > >>>>>> The indicated packet length is 3946 and the load of data shown is that size. The MTU on both interfaces is 1500. The receiving system received 3 packets. There is a router and switch between them. One of them fragmented that packet. This is part of a SSL/TLS exchange and one side or the other is hanging on this and just dropping the connection. I suspect the packet size is the issue. ssldump complains about the packet too and stops monitoring. Could this possibly be related to the hardware checksums? > >>>>> > >>>>> You have TSO enabled on the interface, so large outgoing TCP packet is pretty normal. > >>>>> It will be split by the NIC. Disable TSO with ifconfig if it interferes with your ssldump. > >>>> > >>>> This is not the behaviour I see with em(4) on a 82573E with all defaults > >>>> used (which includes TSO4). Note that Doug is using msk(4). > >>>> > >>>> I can provide packet captures on both ends of a LAN segment using both > >>>> tcpdump (on the FreeBSD side) and Wireshark (on the Windows side) that > >>>> show a difference in behaviour compared to what Doug sees. > >>> > >>> This is strange. tcpdump sees a (big) TCP segment right before > >>> controller actually transmits it. So if TSO is active for the TCP > >>> segment, you should see a series of small TCP packets on receiver > >>> side(i.e. 3 TCP packets in Doug's case). If you don't see a big TCP > >>> segment with tcpdump on TX path, probably TSO was not used for the > >>> TCP segment. > >>> It's possible for controller to corrupt the TCP segment during > >>> segmentation but Doug's tcpdump looks completely normal to me since > >>> tcpdump sees the segment before TCP segmentation. > >>> > >>>> > >>>> What I see on the FreeBSD side with tcpdump is repeated "bad-len 0" > >>>> messages for payloads which are chunked or segmented as a result of TSO. > >>>> I do not see a 1:1 ratio of "bad-len" entries to chunked payloads; I > >>>> only see one "bad-len" entry for all chunks (up until the next ACK or > >>>> PSH+ACK of course). > >>>> > >>> > >>> I vaguely recall that some users reported similar TSO issues on > >>> various drivers. The root cause of the issue was not identified > >>> though. Personally I couldn't reproduce the issue at that time. > >>> It could be a driver or network stack bug. > >> > >> Beware TSO. It can significantly improve throughput on high speed > >> networks, but it really has issues. > >> > >> TSO segments the data and transmits all of them back-to-back with no > >> delay beyond IFG (the 802.3 mandated space between frames) TSO does > >> not understand congestion control. If there is congestion and TSO > >> sends several frames in a row, it is entirely possible that a queue is > >> full or getting close enough to full to start dropping packets and > >> these segmented frames are excellent candidates. > > > > I'm not saying the drawback of TSO. Sometimes segmented packets > > have malformed IP header length under certain circumstances such > > that these packets were dropped on receiver side. > > How do I configure the msk0 interface in rc.conf to disable tso4? I can easily do it with ifconfig, but don't see how to make sure its disabled after a boot. Adjust your ifconfig_msk0 line in rc.conf to contain "-tso", i.e.: ifconfig_msk0="inet 10.0.1.199 netmask 255.255.255.0 -tso" -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 16:42:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EF1E148D; Thu, 14 Feb 2013 16:42:54 +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 930E1E89; Thu, 14 Feb 2013 16:42:54 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EACMTHVGDaFvO/2dsb2JhbABEhkm6NnOCHwEBBSMEUhsOCgICDRkCWQYTiBKrBZJFgSOPToETA4hmjT6QU4Mlggk X-IronPort-AV: E=Sophos;i="4.84,665,1355115600"; d="scan'208";a="14077934" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 14 Feb 2013 11:41:45 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id CA028B4080; Thu, 14 Feb 2013 11:41:45 -0500 (EST) Date: Thu, 14 Feb 2013 11:41:45 -0500 (EST) From: Rick Macklem To: Marc Fournier Message-ID: <1422247357.3019523.1360860105806.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <9A149E78-BB4F-414D-AAE5-331C5934FF82@hub.org> Subject: Re: 9-STABLE -> NFS -> NetAPP: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Konstantin Belousov , freebsd-stable@freebsd.org, Kostik Belousov , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 16:42:55 -0000 Marc Fournier wrote: > On 2013-02-13, at 3:54 PM, Rick Macklem wrote: >=20 > >> > > The pid that is in "T" state for the "ps auxlH". >=20 > Different server, last kernel update on Jan 22nd, https process this > time instead of du last time. >=20 > I've attached: >=20 > ps auxlH > ps auxlH of just the processes that are in TJ state (6 httpd servers) > procstat output for each of the 6 process >=20 >=20 >=20 >=20 > They are included as attachments =E2=80=A6 if these don't make it through= , let > me know, just figured I'd try and keep it compact ... Ok, I took a look and the interesting process seems to be 16693. It is stopped ("T" state) and several of its threads (22, but not all) have a procstat like this: 16693 104135 httpd - mi_switch+0x186 thread_suspe= nd_check+0x19f sleepq_catch_signals+0x1c5 sleepq_timedwait_sig+0x19 _sleep+0x2ca clnt_vc_call+0x763 clnt_reconnect= _call+0xfb newnfs_request+0xadb nfscl_request+0x72 nfsrpc_accessrpc+0x1df nfs34_acc= ess_otw+0x56 nfs_access+0x306 vn_open_cred+0x5a8 kern_openat+0x20a amd64_syscall+0x540 Xfast_syscall+0= xf7=20 The sleep in clnt_vc_call is waiting for an RPC reply (while a vnode lock is held) with PCATCH | PBDRY flags, since it interruptible. I can see that the thread_suspend_check() has a 1 argument (return_instead = =3D=3D 1), since there is only one call to thread_suspend_check() in sleepq_catch_sign= als(). When looking at thread_suspend_check(), I basically got lost, although it seems that it can only "return_instead" if there is a single thread and not multiple threads doing this. If these threads are stuck here and won't return from msleep(), that would explain the hang. If they would wakeup and return from the msleep() when a wakeup occurs, it would suggest that there is a lost reply or similar, so the wakeup isn't occurring. I also don't know if a timeout of the msleep() will still occur and make the msleep() return? Although it wasn't done to fix this, it looks like jhb@'s recent patch to head (r246417) might fix this, since it reworks how STOP signals are handle= d for interruptible mounts. Hopefully kib or jhb can provide more insight. Btw Marc, if you just want this problem to go away, I suspect getting rid of the "intr" mount option would do that. rick From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 18:33:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D0FE0BAD for ; Thu, 14 Feb 2013 18:33:13 +0000 (UTC) (envelope-from karl@denninger.net) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 8B501622 for ; Thu, 14 Feb 2013 18:33:13 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.6/8.13.1) with ESMTP id r1EI3ld9054273 for ; Thu, 14 Feb 2013 12:03:47 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Thu Feb 14 12:03:47 2013 Message-ID: <511D26FE.5040004@denninger.net> Date: Thu, 14 Feb 2013 12:03:42 -0600 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Ipsec VPN tunnel from a Win/7 box? X-Enigmail-Version: 1.5 X-Antivirus: avast! (VPS 130214-0, 02/14/2013), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 18:33:13 -0000 I read around the net that using racoon and the kernel-based IPSEC options do not work with Windows 7..... Is there a configuration that does? -- -- Karl Denninger /The Market Ticker ®/ Cuda Systems LLC From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 19:17:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 19CDB458; Thu, 14 Feb 2013 19:17:30 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id DA34B810; Thu, 14 Feb 2013 19:17:29 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.188]) by hub.org (Postfix) with ESMTP id 4D4E4F14B6C; Thu, 14 Feb 2013 15:17:28 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.188]) (amavisd-maia, port 10024) with ESMTP id 58328-03; Thu, 14 Feb 2013 19:17:28 +0000 (UTC) Received: from [10.5.250.150] (remote.ilcs.sd63.bc.ca [142.31.148.2]) by hub.org (Postfix) with ESMTPA id 1525BF14B6B; Thu, 14 Feb 2013 15:17:26 -0400 (AST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 9-STABLE -> NFS -> NetAPP: From: "Marc G. Fournier" In-Reply-To: <1422247357.3019523.1360860105806.JavaMail.root@erie.cs.uoguelph.ca> Date: Thu, 14 Feb 2013 11:17:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <66254EB1-3E15-4DBF-AFA6-FFB9AC7701DB@hub.org> References: <1422247357.3019523.1360860105806.JavaMail.root@erie.cs.uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1499) Cc: Konstantin Belousov , freebsd-stable@freebsd.org, Kostik Belousov , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 19:17:30 -0000 On 2013-02-14, at 08:41 , Rick Macklem wrote: >=20 > Btw Marc, if you just want this problem to go away, I suspect getting = rid > of the "intr" mount option would do that. Am more interested in fixing the problem (if possible) then just masking = it, but ... Based on the man page for mount_nfs, wouldn't that have the opposite = effect: intr Make the mount interruptible, which implies that = file system calls that are delayed due to an = unresponsive server will fail with EINTR when a termination = signal is posted for the process. I may be mis-reading, but from the above it sounds like a -9 *should* = terminate the process if intr is enabled, while with it disabled, it = would ignore it =85 ? From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 19:34:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5AF9DD3C for ; Thu, 14 Feb 2013 19:34:49 +0000 (UTC) (envelope-from bill@celestial.com) Received: from dorsai-02.celestial.com (dorsai-02.celestial.com [192.136.111.19]) by mx1.freebsd.org (Postfix) with ESMTP id 14BAF8D9 for ; Thu, 14 Feb 2013 19:34:48 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by dorsai-02.celestial.com (Postfix) with ESMTP id 0956C206299C for ; Thu, 14 Feb 2013 11:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at celestial.com Received: from dorsai-02.celestial.com ([127.0.0.1]) by localhost (dorsai-02.celestial.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id td3tSWuE+tRu for ; Thu, 14 Feb 2013 11:29:41 -0800 (PST) Received: from ayn.mi.celestial.com (hayek.celestial.com [192.136.111.12]) by dorsai-02.celestial.com (Postfix) with ESMTP id D048D2061C7E for ; Thu, 14 Feb 2013 11:29:41 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by ayn.mi.celestial.com (Postfix) with ESMTP id 6AA7344F9284; Thu, 14 Feb 2013 11:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at mi.celestial.com Received: from ayn.mi.celestial.com ([127.0.0.1]) by localhost (ayn.mi.celestial.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ojuSV-guzO3q; Thu, 14 Feb 2013 11:29:21 -0800 (PST) Received: by ayn.mi.celestial.com (Postfix, from userid 203) id 5825144F9283; Thu, 14 Feb 2013 11:29:21 -0800 (PST) Date: Thu, 14 Feb 2013 11:29:21 -0800 From: Bill Campbell To: freebsd-stable@freebsd.org Subject: Re: Ipsec VPN tunnel from a Win/7 box? Message-ID: <20130214192921.GA17901@ayn.mi.celestial.com> Mail-Followup-To: freebsd-stable@freebsd.org References: <511D26FE.5040004@denninger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <511D26FE.5040004@denninger.net> User-Agent: Mutt/1.5.19 OpenPKG/CURRENT (2009-01-05) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: freebsd@celestial.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 19:34:49 -0000 On Thu, Feb 14, 2013, Karl Denninger wrote: >I read around the net that using racoon and the kernel-based IPSEC >options do not work with Windows 7..... > >Is there a configuration that does? I don't know about IPsec, but OpenVPN works very nicely. Bill Bill -- INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax: (206) 232-9186 Skype: jwccsllc (206) 855-5792 Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes...Such laws make things worse for the assaulted and better for the assailants. --- http://www.lewrockwell.com/alston/alston60.1.html From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 19:43: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]) by hub.freebsd.org (Postfix) with ESMTP id 3C2F910D for ; Thu, 14 Feb 2013 19:43:25 +0000 (UTC) (envelope-from karl@denninger.net) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id D967E964 for ; Thu, 14 Feb 2013 19:43:24 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.6/8.13.1) with ESMTP id r1EJhNS2076551 for ; Thu, 14 Feb 2013 13:43:23 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Thu Feb 14 13:43:23 2013 Message-ID: <511D3E56.9060103@denninger.net> Date: Thu, 14 Feb 2013 13:43:18 -0600 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Ipsec VPN tunnel from a Win/7 box? References: <511D26FE.5040004@denninger.net> <20130214192921.GA17901@ayn.mi.celestial.com> In-Reply-To: <20130214192921.GA17901@ayn.mi.celestial.com> X-Enigmail-Version: 1.5 X-Antivirus: avast! (VPS 130214-0, 02/14/2013), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 19:43:25 -0000 On 2/14/2013 1:29 PM, Bill Campbell wrote: > On Thu, Feb 14, 2013, Karl Denninger wrote: >> I read around the net that using racoon and the kernel-based IPSEC >> options do not work with Windows 7..... >> >> Is there a configuration that does? > I don't know about IPsec, but OpenVPN works very nicely. > > Bill I can get PPTP to come up with mpd5, but IPSEC is a better option if it can be made to work.. thus far no joy in that direction though. -- -- Karl Denninger /The Market Ticker ®/ Cuda Systems LLC From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 20:37:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A1AA4F86 for ; Thu, 14 Feb 2013 20:37:50 +0000 (UTC) (envelope-from januszbulik@googlemail.com) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by mx1.freebsd.org (Postfix) with ESMTP id 5DF74BF5 for ; Thu, 14 Feb 2013 20:37:50 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id o13so147540qaj.1 for ; Thu, 14 Feb 2013 12:37:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=pqT8i5fXCsV3g8zQmjNnbdgD7dw56YYtMV3rav+i9ps=; b=hK9K9aqPiM8+IZ71E6Fk+0I3jV1FefuZ4QymS6z3N0rAqgfUHCWLufwMGoDXssMcRr WLXGgobf6jhKL17EH7TUiVLdGFPdzqPGHZk+tzFNy5CgfNh2o/cIouQINbm4ERQyl3mf 49OHfsLEPhLX8aprUKF0xvDoVKnuZAOBMhIsYZe/LPFahzDwfxPqkELIynNb/A2Zk+ri kHW2h4KQY2OcDICYGgCAV0ID0204/Wd5Iqpiyxmi0n0x6p8bqFdtDGIXy3QOCh7Kg8Fz SrDuNyrGdMYcERl8VeVJ15VzVL7jplC2CqEtMW54JXCfY8krTyRsFUA6RCTYFF4nrBFt w82A== MIME-Version: 1.0 X-Received: by 10.224.76.198 with SMTP id d6mr1182639qak.30.1360874264677; Thu, 14 Feb 2013 12:37:44 -0800 (PST) Received: by 10.229.52.132 with HTTP; Thu, 14 Feb 2013 12:37:44 -0800 (PST) Date: Thu, 14 Feb 2013 21:37:44 +0100 Message-ID: Subject: NFS resources, how to check version From: Janusz Bulik To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-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, 14 Feb 2013 20:37:50 -0000 Hello, I set up NFSv4 server. To make sure I set vfs.nfsd.server_min_nfsvers=4. I can check its version, for example, by tcpduming and then I can see in wireshark lines like: Network File System Program Version: 4 V4 Procedure: COMPOUND.... .... is there any easier way to check its version? I see there is nfsstat -e option which shows delegs and locks. But all other ones are combined with nfsv3 I guess (On Ubuntu there are separate lines: v3 and v4) and on the client side, is it possible to check which version is exported or mounted? something like % showmount -e nfsserver Is forcing mount to use nfsv4 100% sure? (mount -t nfs -o nfsv4 ....) and btw. Is forcing mount to use -sec=krb5 (with -sec=sys:krb5:krb5i:krb5p in /etc/exports) also 100% sure? because it mounts and doesn't give ticket for nfs/nfsserver. So, I guess if -sec=krb5 is not available, it mounts with -sec=sys, right? With -sec=krb5:krb5i:krb5p in /etc/exports it doesn't mount. I am wondering if you force -o nfsv4, it wouldn't mount it like nfsv3. Happy Valentines! -- Best wishes Janusz From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 20: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]) by hub.freebsd.org (Postfix) with ESMTP id BABE9166 for ; Thu, 14 Feb 2013 20:40:03 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 5688BC32 for ; Thu, 14 Feb 2013 20:40:02 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id ez12so398806wid.5 for ; Thu, 14 Feb 2013 12:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=WOLFw9Wn7TgUWxVCop3srX3Z2Y7HHT9nDUKoVKLn5/Q=; b=zncSqkwHjrhV/TCDNFyMricgw+2gyH4IVKJY2ZqmwiUvZd7OnEoQzndLFd7lAbrEOg 6jFf7Xx9ZbU10cH8bpGLi1io4tQSew5HespYtpR9bT/ZkYPAe5aYpHbWvVxfLuXej5ql gG0eTfLe+/TFyLPb36TwcBkbYITP1jq1qXtx+V8fLKybzmHxi9UG2PFFILoXTLOvMUsi 6Tnw3LBQEdejKb7gplTK2b2hjrmejiYLhUD166SpSGVBHCcnprjjikyyzt0CoohLKiE3 iouTr+PeGmkZRAC7bAaVACYu5IEnAU+XYaJ5a392mqJW3FqgpjygOkWlAKicqDIhz1sc xY/g== X-Received: by 10.194.110.69 with SMTP id hy5mr159141wjb.1.1360874402089; Thu, 14 Feb 2013 12:40:02 -0800 (PST) Received: from melon.malikania.fr (177.33.91.91.rev.sfr.net. [91.91.33.177]) by mx.google.com with ESMTPS id hb9sm1483927wib.3.2013.02.14.12.40.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 14 Feb 2013 12:40:01 -0800 (PST) From: David Demelier To: freebsd-stable@freebsd.org Subject: Re: Panic at shutdown Date: Thu, 14 Feb 2013 21:39:54 +0100 Message-ID: <3573487.tLQXrFnTMD@melon.malikania.fr> User-Agent: KMail/4.9.5 (FreeBSD/9.1-RELEASE; KDE/4.9.5; amd64; ; ) In-Reply-To: References: <51127767.1030007@gmail.com> <2872289.1yXr0e1VeO@melon.malikania.fr> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Cc: Ronald Klop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 20:40:03 -0000 Le mardi 12 f=E9vrier 2013 21:42:01 Ronald Klop a =E9crit : > On Tue, 12 Feb 2013 19:44:49 +0100, David Demelier >=20 > wrote: > > Le mardi 12 f=E9vrier 2013 10:01:10 Andriy Gapon a =E9crit : > >> on 12/02/2013 09:57 David Demelier said the following: > >> > Yes I have added debugging option in my kernel. I have makeoptio= ns > >> > DEBUG=3D-g in my config. Do I need more ? > >>=20 > >> .symbols? > >=20 > > I don't understand what you are saying, I have > > /boot/kernel/kernel.symbols. > > Please tell me what I'm doing wrong. I've just read and done the st= eps > > written > > there : > >=20 > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug= - > > gdb.html > >=20 > > So I've run > >=20 > > # cd /usr/obj/usr/src/sys/Melon > > # kgdb kernel.debug /var/crash/vmcore.0 >=20 > Why not something like kgdb /boot/kernel/kernel.symbols > /var/crash/vmcore.0? > That looks like what the manual page of kgdb seems to suggest. >=20 > Regards, > Ronald. >=20 > > and that's the only trace I get using bt full : > >=20 > > 229 #define IS_BSP() (PCPU_GET(cpuid) =3D=3D 0) > > (kgdb) bt full > > #0 doadump (textdump=3D) at pcpu.h:229 > > No locals. > > #1 0x0000000000000000 in ?? () > > No symbol table info available. > >=20 > >=20 > > -- > > David Demelier > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebs= d.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" Today I have a little bit more : #0 0xffffffff804f358b in isbufbusy (bp=3D0xfffffe0003810480) at=20 /usr/src/sys/kern/kern_shutdown.c:280 280 if (((bp->b_flags & (B_INVAL | B_PERSISTENT)) =3D=3D 0 = && (kgdb) bt full #0 0xffffffff804f358b in isbufbusy (bp=3D0xfffffe0003810480) at=20 /usr/src/sys/kern/kern_shutdown.c:280 No locals. #1 0x0000000000000004 in ?? () No symbol table info available. #2 0xffffffff804f3aa6 in kern_reboot (howto=3D260) at=20 /usr/src/sys/kern/kern_shutdown.c:451 _ep =3D (struct eventhandler_entry *) 0x100 _el =3D (struct eventhandler_list *) 0xffffffff804f35b3 first_buf_printf =3D 1 #3 0xffffffff804f3f69 in panic (fmt=3DVariable "fmt" is not available.= ) at /usr/src/sys/kern/kern_shutdown.c:624 td =3D (struct thread *) 0x1 bootopt =3D 260 newpanic =3D 1 ap =3D {{gp_offset =3D 16, fp_offset =3D 48, overflow_arg_area = =3D=20 0xffffff80daaf0420, reg_save_area =3D 0xffffff80daaf0350}} panic_cpu =3D 0 buf =3D "general protection fault", '\0' #4 0xffffffff806fcf69 in trap_fatal (frame=3D0x9, eva=3DVariable "eva"= is not=20 available. ) at /usr/src/sys/amd64/amd64/trap.c:851 code =3D Variable "code" is not available. --=20 David Demelier From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 20:43:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2AF11297 for ; Thu, 14 Feb 2013 20:43:24 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id 0AD5CCCC for ; Thu, 14 Feb 2013 20:43:24 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 0D6p1l00A1HpZEsA1LjPqa; Thu, 14 Feb 2013 20:43:23 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta14.emeryville.ca.mail.comcast.net with comcast id 0LjN1l00M1t3BNj8aLjNTm; Thu, 14 Feb 2013 20:43:23 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 81E4573A1D; Thu, 14 Feb 2013 12:43:22 -0800 (PST) Date: Thu, 14 Feb 2013 12:43:22 -0800 From: Jeremy Chadwick To: YongHyeon PYUN Subject: Re: Unusual TCP/IP Packet Size Message-ID: <20130214204322.GA90281@icarus.home.lan> References: <96AE8BD1-79C2-4743-854F-B8386C54E4A1@lafn.org> <511B6B21.5030606@rdtc.ru> <20130213130059.GA57337@icarus.home.lan> <20130214013723.GB2945@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130214013723.GB2945@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360874603; bh=BgLgXtmguZjz72QwKFD9/IesOAWND7sjcKnYk6kEV18=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=rGtSULX0DSUolCGl7rWyiLVIAzTmTOCYNRnwQODnpC6HhETQGWQkTsnFi+KoXIIKp spdBu7ORcYu/SzvHAhaygvk7agnhR3wyStK5QmgU18EizYfr51pHRkl7dUhYntybXp yVL0lea5ZntaqOy48abh6ZNzQa5nFBVQ9jtIMTMul5w3L8+2K9WnNaxtu2hBaWCG3s LrCjKwpmlKIU6PgT+vFnSkVCiZaMKBVdCF0ko++WFI+k5jNE+qybX3Fqr3usidNmom zoEna5lxnbdw87AwXZVMfz94mqmNa18sx1XawP0miHjy2IyjUjDE82VeM4Wug7RLmy H+iT2rlLKtMnA== Cc: freebsd-stable@freebsd.org, Eugene Grosbein , yongari@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, 14 Feb 2013 20:43:24 -0000 On Thu, Feb 14, 2013 at 10:37:23AM +0900, YongHyeon PYUN wrote: > On Wed, Feb 13, 2013 at 05:00:59AM -0800, Jeremy Chadwick wrote: > > On Wed, Feb 13, 2013 at 05:29:53PM +0700, Eugene Grosbein wrote: > > > 13.02.2013 17:25, Doug Hardie ??????????: > > > > Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has the following interface: > > > > > > > > msk0: flags=8843 metric 0 mtu 1500 > > > > options=c011b > > > > ether 00:11:2f:2a:c7:03 > > > > inet 10.0.1.199 netmask 0xffffff00 broadcast 10.0.1.255 > > > > inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1 > > > > nd6 options=29 > > > > media: Ethernet autoselect (100baseTX ) > > > > status: active > > > > > > > > > > > > It sent the following packet: (data content abbreviated) > > > > > > > > 02:14:42.081617 IP 10.0.1.199.443 > 10.0.1.2.61258: Flags [P.], seq 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr 920110183], length 3946 > > > > 0x0000: 4500 0f9e ea89 4000 4006 2a08 0a00 01c7 E.....@.@.*..... > > > > 0x0010: 0a00 0102 01bb ef4a ece1 680b ae37 1bbc .......J..h..7.. > > > > 0x0020: 8018 0410 3407 0000 0101 080a 17f3 8ff8 ....4...??????. > > > > > > > > > > > > The indicated packet length is 3946 and the load of data shown is that size. The MTU on both interfaces is 1500. The receiving system received 3 packets. There is a router and switch between them. One of them fragmented that packet. This is part of a SSL/TLS exchange and one side or the other is hanging on this and just dropping the connection. I suspect the packet size is the issue. ssldump complains about the packet too and stops monitoring. Could this possibly be related to the hardware checksums? > > > > > > You have TSO enabled on the interface, so large outgoing TCP packet is pretty normal. > > > It will be split by the NIC. Disable TSO with ifconfig if it interferes with your ssldump. > > > > This is not the behaviour I see with em(4) on a 82573E with all defaults > > used (which includes TSO4). Note that Doug is using msk(4). > > > > I can provide packet captures on both ends of a LAN segment using both > > tcpdump (on the FreeBSD side) and Wireshark (on the Windows side) that > > show a difference in behaviour compared to what Doug sees. > > This is strange. tcpdump sees a (big) TCP segment right before > controller actually transmits it. So if TSO is active for the TCP > segment, you should see a series of small TCP packets on receiver > side(i.e. 3 TCP packets in Doug's case). If you don't see a big TCP > segment with tcpdump on TX path, probably TSO was not used for the > TCP segment. > It's possible for controller to corrupt the TCP segment during > segmentation but Doug's tcpdump looks completely normal to me since > tcpdump sees the segment before TCP segmentation. Let me explain what I'm referring to. In the below tcpdump on the server, you'll find 5 "bad-len 0" messages. These correlate directly with TCP payloads that exceed MTU -- this is verified by comparing to the number of lines labelled "TCP segment of reassembled PDU" **that exceed MTU (>1500)** in Wireshark (when analysing the same server capture). Thus, the "bad-len 0" messages in tcpdump are indicators of TSO being used. Doug's capture with msk(4) + TSO shows a TCP length that exceeds MTU, yet my capture with em(4) + TSO shows "bad-len 0". Wireshark seems to decode server capture correctly, so I'm inclined to think this is a libpcap/tcpdump quirk/bug of sorts. I just find it very strange that NIC difference manifests itself like this (and in some regards, concerns me). I'm happy to provide the pcap files from both server and client if someone wants to do the analysis, as well as a "verbose" output from Wireshark (vs. just the summary lines) if all packet fields are desired. Server = 192.168.1.51 (FreeBSD, Intel 82573E, em(4), with TSO) Client = 192.168.1.50 (Windows XP SP3) Server capture (tcpdump -p -i em0 -n -s 0 -w server.pcap): 12:14:54.512542 IP 192.168.1.50.1300 > 192.168.1.51.80: Flags [S], seq 375412185, win 65535, options [mss 1460,nop,wscale 3,nop,nop,sackOK], length 0 12:14:54.512576 IP 192.168.1.51.80 > 192.168.1.50.1300: Flags [S.], seq 339580135, ack 375412186, win 65535, options [mss 1460,nop,wscale 6,sackOK,eol], length 0 12:14:54.512659 IP 192.168.1.50.1300 > 192.168.1.51.80: Flags [.], ack 1, win 64240, length 0 12:14:54.512784 IP 192.168.1.50.1300 > 192.168.1.51.80: Flags [P.], seq 1:330, ack 1, win 64240, length 329 12:14:54.515194 IP 192.168.1.51.80 > 192.168.1.50.1300: Flags [P.], seq 1:279, ack 330, win 1026, length 278 12:14:54.515230 IP bad-len 0 12:14:54.515410 IP 192.168.1.50.1300 > 192.168.1.51.80: Flags [.], ack 1739, win 64240, length 0 12:14:54.515423 IP bad-len 0 12:14:54.515429 IP 192.168.1.50.1300 > 192.168.1.51.80: Flags [.], ack 4382, win 64240, length 0 12:14:54.515439 IP bad-len 0 12:14:54.515657 IP 192.168.1.50.1300 > 192.168.1.51.80: Flags [.], ack 7858, win 64240, length 0 12:14:54.515667 IP bad-len 0 12:14:54.515674 IP 192.168.1.50.1300 > 192.168.1.51.80: Flags [.], ack 10778, win 64240, length 0 12:14:54.515682 IP bad-len 0 12:14:54.515688 IP 192.168.1.50.1300 > 192.168.1.51.80: Flags [.], ack 13144, win 64240, length 0 12:14:54.515907 IP 192.168.1.50.1300 > 192.168.1.51.80: Flags [.], ack 16064, win 64240, length 0 12:14:54.515913 IP 192.168.1.50.1300 > 192.168.1.51.80: Flags [.], ack 19540, win 64240, length 0 12:14:54.515918 IP 192.168.1.50.1300 > 192.168.1.51.80: Flags [.], ack 22460, win 64240, length 0 12:14:54.515923 IP 192.168.1.50.1300 > 192.168.1.51.80: Flags [.], ack 24354, win 64240, length 0 12:14:59.516217 IP 192.168.1.51.80 > 192.168.1.50.1300: Flags [F.], seq 24354, ack 330, win 1026, length 0 12:14:59.516408 IP 192.168.1.50.1300 > 192.168.1.51.80: Flags [.], ack 24355, win 64240, length 0 12:14:59.516425 IP 192.168.1.50.1300 > 192.168.1.51.80: Flags [F.], seq 330, ack 24355, win 64240, length 0 12:14:59.516454 IP 192.168.1.51.80 > 192.168.1.50.1300: Flags [.], ack 331, win 1026, length 0 Server capture (server.pcap) analysed by Wireshark: No. Time Source Destination Protocol Length Info 1 12:14:54.512542 192.168.1.50 192.168.1.51 TCP 66 1300 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=8 SACK_PERM=1 2 12:14:54.512576 192.168.1.51 192.168.1.50 TCP 66 80 > 1300 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=64 SACK_PERM=1 3 12:14:54.512659 192.168.1.50 192.168.1.51 TCP 60 1300 > 80 [ACK] Seq=1 Ack=1 Win=513920 Len=0 4 12:14:54.512784 192.168.1.50 192.168.1.51 HTTP 383 GET /wtf.jpg HTTP/1.1 5 12:14:54.515194 192.168.1.51 192.168.1.50 TCP 332 [TCP segment of a reassembled PDU] 6 12:14:54.515230 192.168.1.51 192.168.1.50 TCP 4157 [TCP segment of a reassembled PDU] 7 12:14:54.515410 192.168.1.50 192.168.1.51 TCP 60 1300 > 80 [ACK] Seq=330 Ack=1739 Win=513920 Len=0 8 12:14:54.515423 192.168.1.51 192.168.1.50 TCP 3530 [TCP segment of a reassembled PDU] 9 12:14:54.515429 192.168.1.50 192.168.1.51 TCP 60 1300 > 80 [ACK] Seq=330 Ack=4382 Win=513920 Len=0 10 12:14:54.515439 192.168.1.51 192.168.1.50 TCP 5340 [TCP segment of a reassembled PDU] 11 12:14:54.515657 192.168.1.50 192.168.1.51 TCP 60 1300 > 80 [ACK] Seq=330 Ack=7858 Win=513920 Len=0 12 12:14:54.515667 192.168.1.51 192.168.1.50 TCP 6450 [TCP segment of a reassembled PDU] 13 12:14:54.515674 192.168.1.50 192.168.1.51 TCP 60 1300 > 80 [ACK] Seq=330 Ack=10778 Win=513920 Len=0 14 12:14:54.515682 192.168.1.51 192.168.1.50 HTTP 4868 HTTP/1.1 200 OK (JPEG JFIF image) 15 12:14:54.515688 192.168.1.50 192.168.1.51 TCP 60 1300 > 80 [ACK] Seq=330 Ack=13144 Win=513920 Len=0 16 12:14:54.515907 192.168.1.50 192.168.1.51 TCP 60 1300 > 80 [ACK] Seq=330 Ack=16064 Win=513920 Len=0 17 12:14:54.515913 192.168.1.50 192.168.1.51 TCP 60 1300 > 80 [ACK] Seq=330 Ack=19540 Win=513920 Len=0 18 12:14:54.515918 192.168.1.50 192.168.1.51 TCP 60 1300 > 80 [ACK] Seq=330 Ack=22460 Win=513920 Len=0 19 12:14:54.515923 192.168.1.50 192.168.1.51 TCP 60 1300 > 80 [ACK] Seq=330 Ack=24354 Win=513920 Len=0 20 12:14:59.516217 192.168.1.51 192.168.1.50 TCP 54 80 > 1300 [FIN, ACK] Seq=24354 Ack=330 Win=65664 Len=0 21 12:14:59.516408 192.168.1.50 192.168.1.51 TCP 60 1300 > 80 [ACK] Seq=330 Ack=24355 Win=513920 Len=0 22 12:14:59.516425 192.168.1.50 192.168.1.51 TCP 60 1300 > 80 [FIN, ACK] Seq=330 Ack=24355 Win=513920 Len=0 23 12:14:59.516454 192.168.1.51 192.168.1.50 TCP 54 80 > 1300 [ACK] Seq=24355 Ack=331 Win=65664 Len=0 Client capture: No. Time Source Destination Protocol Length Info 1 12:14:54.555808000 192.168.1.50 192.168.1.51 TCP 66 1300 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=8 SACK_PERM=1 2 12:14:54.555978000 192.168.1.51 192.168.1.50 TCP 66 80 > 1300 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=64 SACK_PERM=1 3 12:14:54.555988000 192.168.1.50 192.168.1.51 TCP 54 1300 > 80 [ACK] Seq=1 Ack=1 Win=513920 Len=0 4 12:14:54.556057000 192.168.1.50 192.168.1.51 HTTP 383 GET /wtf.jpg HTTP/1.1 5 12:14:54.558602000 192.168.1.51 192.168.1.50 TCP 332 [TCP segment of a reassembled PDU] 6 12:14:54.558674000 192.168.1.51 192.168.1.50 TCP 1514 [TCP segment of a reassembled PDU] 7 12:14:54.558684000 192.168.1.50 192.168.1.51 TCP 54 1300 > 80 [ACK] Seq=330 Ack=1739 Win=513920 Len=0 8 12:14:54.558703000 192.168.1.51 192.168.1.50 TCP 1514 [TCP segment of a reassembled PDU] 9 12:14:54.558708000 192.168.1.51 192.168.1.50 TCP 1237 [TCP segment of a reassembled PDU] 10 12:14:54.558715000 192.168.1.50 192.168.1.51 TCP 54 1300 > 80 [ACK] Seq=330 Ack=4382 Win=513920 Len=0 11 12:14:54.558869000 192.168.1.51 192.168.1.50 TCP 1514 [TCP segment of a reassembled PDU] 12 12:14:54.558883000 192.168.1.51 192.168.1.50 TCP 1514 [TCP segment of a reassembled PDU] 13 12:14:54.558891000 192.168.1.51 192.168.1.50 TCP 610 [TCP segment of a reassembled PDU] 14 12:14:54.558898000 192.168.1.50 192.168.1.51 TCP 54 1300 > 80 [ACK] Seq=330 Ack=7858 Win=513920 Len=0 15 12:14:54.558910000 192.168.1.51 192.168.1.50 TCP 1514 [TCP segment of a reassembled PDU] 16 12:14:54.558925000 192.168.1.51 192.168.1.50 TCP 1514 [TCP segment of a reassembled PDU] 17 12:14:54.558931000 192.168.1.50 192.168.1.51 TCP 54 1300 > 80 [ACK] Seq=330 Ack=10778 Win=513920 Len=0 18 12:14:54.558947000 192.168.1.51 192.168.1.50 TCP 1514 [TCP segment of a reassembled PDU] 19 12:14:54.558950000 192.168.1.51 192.168.1.50 TCP 960 [TCP segment of a reassembled PDU] 20 12:14:54.558956000 192.168.1.50 192.168.1.51 TCP 54 1300 > 80 [ACK] Seq=330 Ack=13144 Win=513920 Len=0 21 12:14:54.559116000 192.168.1.51 192.168.1.50 TCP 1514 [TCP segment of a reassembled PDU] 22 12:14:54.559132000 192.168.1.51 192.168.1.50 TCP 1514 [TCP segment of a reassembled PDU] 23 12:14:54.559140000 192.168.1.50 192.168.1.51 TCP 54 1300 > 80 [ACK] Seq=330 Ack=16064 Win=513920 Len=0 24 12:14:54.559157000 192.168.1.51 192.168.1.50 TCP 1514 [TCP segment of a reassembled PDU] 25 12:14:54.559161000 192.168.1.51 192.168.1.50 TCP 1514 [TCP segment of a reassembled PDU] 26 12:14:54.559165000 192.168.1.51 192.168.1.50 TCP 610 [TCP segment of a reassembled PDU] 27 12:14:54.559171000 192.168.1.50 192.168.1.51 TCP 54 1300 > 80 [ACK] Seq=330 Ack=19540 Win=513920 Len=0 28 12:14:54.559189000 192.168.1.51 192.168.1.50 TCP 1514 [TCP segment of a reassembled PDU] 29 12:14:54.559193000 192.168.1.51 192.168.1.50 TCP 1514 [TCP segment of a reassembled PDU] 30 12:14:54.559199000 192.168.1.50 192.168.1.51 TCP 54 1300 > 80 [ACK] Seq=330 Ack=22460 Win=513920 Len=0 31 12:14:54.559214000 192.168.1.51 192.168.1.50 TCP 1514 [TCP segment of a reassembled PDU] 32 12:14:54.559218000 192.168.1.51 192.168.1.50 HTTP 488 HTTP/1.1 200 OK (JPEG JFIF image) 33 12:14:54.559229000 192.168.1.50 192.168.1.51 TCP 54 1300 > 80 [ACK] Seq=330 Ack=24354 Win=513920 Len=0 34 12:14:59.559591000 192.168.1.51 192.168.1.50 TCP 60 80 > 1300 [FIN, ACK] Seq=24354 Ack=330 Win=65664 Len=0 35 12:14:59.559610000 192.168.1.50 192.168.1.51 TCP 54 1300 > 80 [ACK] Seq=330 Ack=24355 Win=513920 Len=0 36 12:14:59.559668000 192.168.1.50 192.168.1.51 TCP 54 1300 > 80 [FIN, ACK] Seq=330 Ack=24355 Win=513920 Len=0 37 12:14:59.559828000 192.168.1.51 192.168.1.50 TCP 60 80 > 1300 [ACK] Seq=24355 Ack=331 Win=65664 Len=0 -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 20:43:47 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 58CD83B9 for ; Thu, 14 Feb 2013 20:43:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 36AC3CEE for ; Thu, 14 Feb 2013 20:43:47 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3D787B926; Thu, 14 Feb 2013 15:43:46 -0500 (EST) From: John Baldwin To: CeDeROM Subject: Re: 9.1-RELEASE AMD64 crash under VBox 4.2.6 when IO APIC is disabled Date: Thu, 14 Feb 2013 15:37:24 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201302131048.06370.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201302141537.24701.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 14 Feb 2013 15:43:46 -0500 (EST) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 20:43:47 -0000 On Wednesday, February 13, 2013 6:56:06 pm CeDeROM wrote: > On Wed, Feb 13, 2013 at 4:48 PM, John Baldwin wrote: > >> The simple answer that I have deduced is that APIC is MANDATORY for > >> AMD64 machines and they won't run otherwise? This is why generic AMD64 > >> install fails when no APIC is enabled in the VBox? > > > > No, it is not quite like that. x86 machines have two entirely different > > sets of interrupt controllers. (...) > > Hello John :-) Things now are more clear to me, thank you for your > extensive explanation!! :-) I am wondering in that case if it wouldn't > be a good idea to put atpci (old x86 IRQ handler) in the GENERIC > configuration, or at least in the default installer kernel, so it is a > safe fallback for a AMD64 machines with no APIC support, as for > example VBox with APIC disabled..? Is atpic removed on purpose so it > enforces use of new APIC and so better performance? Real hardware should always use device apic on amd64. Even for a VM you should prefer apic. That is, I think you should just enable APIC when using VBox. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 23:37:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9D82CA0B for ; Thu, 14 Feb 2013 23:37:28 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id DC087372 for ; Thu, 14 Feb 2013 23:37:27 +0000 (UTC) Received: (qmail 90612 invoked by uid 89); 14 Feb 2013 23:37:20 -0000 Received: by simscan 1.4.0 ppid: 90607, pid: 90609, t: 0.0547s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:16685 Received: from unknown (HELO ewzw044.ewadmin.local) (rainer@ultra-secure.de@212.71.117.87) by mail.ultra-secure.de with ESMTPA; 14 Feb 2013 23:37:20 -0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Why does poudriere always rebuild nginx and GraphicsMagick13? From: Rainer Duffner In-Reply-To: <20130212221103.GG12760@ithaqua.etoilebsd.net> Date: Fri, 15 Feb 2013 00:37:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6088089D-3E61-4C82-94D4-319E48CF718B@ultra-secure.de> References: <20130212221103.GG12760@ithaqua.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1499) Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 23:37:28 -0000 Am 12.02.2013 um 23:11 schrieb Baptiste Daroussin : > On Tue, Feb 12, 2013 at 10:59:28PM +0100, Rainer Duffner wrote: >> Hi, >>=20 >> poudriere 2.2 here, running on 9.1-amd64 >>=20 >> Of the 730-ish ports, whenever I run a build, it always rebuilds the = above two ports. >> Even if nothing changed. >>=20 >> Is there are specific reason for this? >>=20 >> I don't really mind nginx, because it builds so quickly - but = GraphicsMagick takes a bit too long. >=20 > 2.2 is so old :) > please upgrade to at least 2.3.1, lots of things as been fixed since, = and soon > 2.3.2 with lots of other bug fixes. >=20 > I'm sure 2.3.1 fixes your problems, or at least will explain you why = something > is rebuilt (it is now explained during the sanity check) >=20 > regards, > Bapt Hi Baptiste, so I upgraded to 2.3.1 but it still rebuilds those two ports every = single time I run a bulk build. =85 =3D=3D=3D=3D>> Options changed, deleting: = GraphicsMagick-nox11-1.3.16_1.txz =3D=3D=3D=3D>> Options changed, deleting: nginx-1.2.6,1.txz ... drwxr-xr-x 2 root wheel 512 Dec 21 09:20 GraphicsMagick/ drwxr-xr-x 2 root wheel 512 Dec 21 09:20 GraphicsMagick13/ drwxr-xr-x 2 root wheel 512 Dec 21 09:20 nginx/ Somehow, it thinks the options have changed. Maybe, the options-file has an error? Regards, Rainer From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 00:14:46 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9CC1CFB6 for ; Fri, 15 Feb 2013 00:14:46 +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 610D76DA for ; Fri, 15 Feb 2013 00:14:45 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAAJ9HVGDaFvO/2dsb2JhbABFhkm6LnOCHwEBAQMBAQEBICsgCwUWGAICDRkCKQEJJgYIBwQBHASHawYMql+SNoEjjCcKgx2BEwOIZosLgjOBHY82gyVPgQU1 X-IronPort-AV: E=Sophos;i="4.84,668,1355115600"; d="scan'208";a="14184198" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 14 Feb 2013 19:14:44 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id CF8C5B4090; Thu, 14 Feb 2013 19:14:44 -0500 (EST) Date: Thu, 14 Feb 2013 19:14:44 -0500 (EST) From: Rick Macklem To: Janusz Bulik Message-ID: <1476795337.3038886.1360887284826.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: NFS resources, how to check version MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-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, 15 Feb 2013 00:14:46 -0000 Janusz Bulik wrote: > Hello, > > I set up NFSv4 server. To make sure I set > vfs.nfsd.server_min_nfsvers=4. I can check its version, for example, > by tcpduming and then I can see in wireshark lines like: > Network File System > Program Version: 4 > V4 Procedure: COMPOUND.... > .... > > is there any easier way to check its version? > I see there is nfsstat -e option which shows delegs and locks. But all > other ones are combined with nfsv3 I guess (On Ubuntu there are > separate lines: v3 and v4) > At the server, not that I can think of. As you noted, if you see non-zero values for the OpenOwners etc line when you do "nfsstat -e -s", then some client is using NFSv4. jwd@ was working on some per-client stats, but we need to resurrect that work. (I can't remember if he has a patch for testing lying about these days?) > and on the client side, is it possible to check which version is > exported or mounted? > something like > % showmount -e nfsserver > > Is forcing mount to use nfsv4 100% sure? (mount -t nfs -o nfsv4 ....) > Yes, w.r.t. the FreeBSD client. Also, there is now a "-m" option on nfsstat that you can use on the client to dump exactly what mount options are being used. (It is in head and stable/9, but not 9.1-release.) > and btw. Is forcing mount to use -sec=krb5 (with > -sec=sys:krb5:krb5i:krb5p in /etc/exports) also 100% sure? Nope. I didn't code this and I've never been sure if it the correct thing to do, but the code falls through to using "sys" if it can't get a Kerberos credential. I'm guessing that the original author figured that, if the server cared, it would fail the RPC when a "sys" authenticator was used. > because it mounts and doesn't give ticket for nfs/nfsserver. > So, I guess if -sec=krb5 is not available, it mounts with -sec=sys, > right? It is actually per-RPC. It will try to get a Kerberos credential, but fall through to using "sys" if that fails. > With -sec=krb5:krb5i:krb5p in /etc/exports it doesn't mount. Correct. I think that was the original author's assumption. > I am wondering if you force -o nfsv4, it wouldn't mount it like nfsv3. > Yes, as above. Personally, I think it should always use whatever version the command line option specifies, but that is really up to the "FreeBSD collective". It currently defaults to nfsv3 if no option is specified and, maybe. someday that should change to nfsv4, but it is not that way now. rick > > Happy Valentines! > > -- > Best wishes > Janusz > _______________________________________________ > 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 Feb 15 00:24:47 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 497EC2DA; Fri, 15 Feb 2013 00:24:47 +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 BD30175F; Fri, 15 Feb 2013 00:24:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAMF/HVGDaFvO/2dsb2JhbABFhkm6L3OCHwEBAQQBAQEgBCcgCxsYAgINGQIpAQkmBggHBAEcBIdxDKphkjWBI4wngyeBEwOIZosLgjOBHY82gyVPgQU1 X-IronPort-AV: E=Sophos;i="4.84,668,1355115600"; d="scan'208";a="16767392" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 14 Feb 2013 19:24:40 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 38460B4036; Thu, 14 Feb 2013 19:24:40 -0500 (EST) Date: Thu, 14 Feb 2013 19:24:40 -0500 (EST) From: Rick Macklem To: "Marc G. Fournier" Message-ID: <761286247.3039021.1360887880184.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <66254EB1-3E15-4DBF-AFA6-FFB9AC7701DB@hub.org> Subject: Re: 9-STABLE -> NFS -> NetAPP: 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 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Konstantin Belousov , Kostik Belousov , freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 00:24:47 -0000 Marc Fournier wrote: > On 2013-02-14, at 08:41 , Rick Macklem wrote: >=20 > > > > Btw Marc, if you just want this problem to go away, I suspect > > getting rid > > of the "intr" mount option would do that. >=20 > Am more interested in fixing the problem (if possible) then just > masking it, but ... >=20 > Based on the man page for mount_nfs, wouldn't that have the opposite > effect: >=20 > intr Make the mount interruptible, which implies that file > system calls that are delayed due to an unresponsive > server will fail with EINTR when a termination signal is > posted for the process. >=20 > I may be mis-reading, but from the above it sounds like a -9 *should* > terminate the process if intr is enabled, while with it disabled, it > would ignore it =E2=80=A6 ? >=20 Yes, you have misread it (or english is a wonderfully ambiguous thing, if you prefer;-). For hard mounts (which is what you get if you don't specify either "soft" nor "intr"), the RPCs behave like other I/O subsystems, which means they do non-interruptible sleeps ("D" stat in ps) waiting for server replies and continue to try and complete the RPC "forever". You can't kill off the process/thread with any signal. If "umount -f" of the filesystem works, that terminates the thread(s). Unfortunately, "umount -f" is quite broken again. I have an idea on how to resolve this, but I haven't coded it yet. (The problem is that the process doing "umount -f" gets stuck before it does the VFS_UNMOUNT(), so the NFS client doesn't see it.) rick >=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" From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 00:37:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 724EC45D; Fri, 15 Feb 2013 00:37:29 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 2FD8E7BB; Fri, 15 Feb 2013 00:37:29 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.188]) by hub.org (Postfix) with ESMTP id 67CB61AD2FA6; Thu, 14 Feb 2013 20:37:22 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.188]) (amavisd-maia, port 10024) with ESMTP id 46509-04; Fri, 15 Feb 2013 00:37:22 +0000 (UTC) Received: from [10.5.250.150] (remote.ilcs.sd63.bc.ca [142.31.148.2]) by hub.org (Postfix) with ESMTPA id 2DCA31AD2FA5; Thu, 14 Feb 2013 20:37:21 -0400 (AST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 9-STABLE -> NFS -> NetAPP: From: "Marc G. Fournier" In-Reply-To: <761286247.3039021.1360887880184.JavaMail.root@erie.cs.uoguelph.ca> Date: Thu, 14 Feb 2013 16:37:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7614F404-CD69-479E-BDFA-31451DB9040F@hub.org> References: <761286247.3039021.1360887880184.JavaMail.root@erie.cs.uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1499) Cc: Konstantin Belousov , Kostik Belousov , freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 00:37:29 -0000 On 2013-02-14, at 16:24 , Rick Macklem wrote: > Marc Fournier wrote: >> On 2013-02-14, at 08:41 , Rick Macklem wrote: >>=20 >>>=20 >>> Btw Marc, if you just want this problem to go away, I suspect >>> getting rid >>> of the "intr" mount option would do that. >>=20 >> Am more interested in fixing the problem (if possible) then just >> masking it, but ... >>=20 >> Based on the man page for mount_nfs, wouldn't that have the opposite >> effect: >>=20 >> intr Make the mount interruptible, which implies that file >> system calls that are delayed due to an unresponsive >> server will fail with EINTR when a termination signal is >> posted for the process. >>=20 >> I may be mis-reading, but from the above it sounds like a -9 *should* >> terminate the process if intr is enabled, while with it disabled, it >> would ignore it =85 ? >>=20 > Yes, you have misread it (or english is a wonderfully ambiguous thing, > if you prefer;-). >=20 > For hard mounts (which is what you get if you don't specify either = "soft" > nor "intr"), the RPCs behave like other I/O subsystems, which means = they > do non-interruptible sleeps ("D" stat in ps) waiting for server = replies > and continue to try and complete the RPC "forever". You can't kill off > the process/thread with any signal. >=20 > If "umount -f" of the filesystem works, that terminates the thread(s). > Unfortunately, "umount -f" is quite broken again. I have an idea on > how to resolve this, but I haven't coded it yet. (The problem is that > the process doing "umount -f" gets stuck before it does the = VFS_UNMOUNT(), > so the NFS client doesn't see it.) For how infrequently this problem generally manifests itself, is there = an overall benefit from a debugging standpoint of my leaving intr on = and reporting when it happens, including procstat output, and then = upgrading to latest kernel =85 ? Its an annoyance, but it isn't like it happens daily, so I don't mind = going through the process *towards* having it fixed if there is an = overall benefit =85 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 01:27:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 97D09F7E for ; Fri, 15 Feb 2013 01:27:36 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [78.47.114.122]) by mx1.freebsd.org (Postfix) with ESMTP id 07A1A91A for ; Fri, 15 Feb 2013 01:27:35 +0000 (UTC) Received: (qmail 92664 invoked by uid 89); 15 Feb 2013 01:27:34 -0000 Received: by simscan 1.4.0 ppid: 92659, pid: 92661, t: 0.0596s scanners: attach: 1.4.0 clamav: 0.97.3/m:54/d:16685 Received: from unknown (HELO ewzw044.ewadmin.local) (rainer@ultra-secure.de@212.71.117.87) by mail.ultra-secure.de with ESMTPA; 15 Feb 2013 01:27:34 -0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Why does poudriere always rebuild nginx and GraphicsMagick13? From: Rainer Duffner In-Reply-To: <6088089D-3E61-4C82-94D4-319E48CF718B@ultra-secure.de> Date: Fri, 15 Feb 2013 02:27:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <62B5372A-8DD9-4352-89B0-BDEAC11A5C2C@ultra-secure.de> References: <20130212221103.GG12760@ithaqua.etoilebsd.net> <6088089D-3E61-4C82-94D4-319E48CF718B@ultra-secure.de> To: "freebsd-stable@freebsd.org" X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 01:27:36 -0000 >=20 >=20 > Hi Baptiste, >=20 > so I upgraded to 2.3.1 but it still rebuilds those two ports every = single time I run a bulk build. >=20 > =85 > =3D=3D=3D=3D>> Options changed, deleting: = GraphicsMagick-nox11-1.3.16_1.txz > =3D=3D=3D=3D>> Options changed, deleting: nginx-1.2.6,1.txz > ... >=20 >=20 > drwxr-xr-x 2 root wheel 512 Dec 21 09:20 GraphicsMagick/ > drwxr-xr-x 2 root wheel 512 Dec 21 09:20 GraphicsMagick13/ > drwxr-xr-x 2 root wheel 512 Dec 21 09:20 nginx/ >=20 >=20 > Somehow, it thinks the options have changed. > Maybe, the options-file has an error? >=20 OK, another issue crept up. I started to build www/rt40 and it worked - until I updated it to the = latest commit. Now I get: =3D=3D=3D=3D>> [02] Finished build of www/rt40: Ignored: please select = one of AP_MODPERL, AP_MODFASTCGI, LIGHTTPD, SPAWN_FCGI or BUILTIN But I have: cat /usr/local/etc/poudriere.d/91amd64-options/rt40/options # This file is auto-generated by 'make config'. # Options for rt-4.0.10_1 _OPTIONS_READ=3Drt-4.0.10_1 _FILE_COMPLETE_OPTIONS_LIST=3DDEV GD GPG GRAPHVIZ SSL_MAILGATE MYSQL = ORACLE PGSQL SQLITE AP_MODFASTCGI AP_MODPERL LIGHTTPD SPAWN_FCGI OPTIONS_FILE_UNSET+=3DDEV OPTIONS_FILE_SET+=3DGD OPTIONS_FILE_SET+=3DGPG OPTIONS_FILE_SET+=3DGRAPHVIZ OPTIONS_FILE_SET+=3DSSL_MAILGATE OPTIONS_FILE_UNSET+=3DMYSQL OPTIONS_FILE_UNSET+=3DORACLE OPTIONS_FILE_SET+=3DPGSQL OPTIONS_FILE_UNSET+=3DSQLITE OPTIONS_FILE_UNSET+=3DAP_MODFASTCGI OPTIONS_FILE_UNSET+=3DAP_MODPERL OPTIONS_FILE_UNSET+=3DLIGHTTPD OPTIONS_FILE_SET+=3DSPAWN_FCGI If I run make patch in my local ports tree, with the above options file, = it runs through. Is this a poudriere problem or more of a problem with the port itself? From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 01:36:53 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4B76032E for ; Fri, 15 Feb 2013 01:36:53 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mail.egr.msu.edu (dauterive.egr.msu.edu [35.9.37.168]) by mx1.freebsd.org (Postfix) with ESMTP id 1B5F798C for ; Fri, 15 Feb 2013 01:36:52 +0000 (UTC) Received: from dauterive (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 3A42838559; Thu, 14 Feb 2013 20:29:20 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by dauterive (dauterive.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lr15PF3irFqm; Thu, 14 Feb 2013 20:29:20 -0500 (EST) Received: from daemon.localdomain (daemon.egr.msu.edu [35.9.44.65]) by mail.egr.msu.edu (Postfix) with ESMTP id D1B4F38554; Thu, 14 Feb 2013 20:29:19 -0500 (EST) Received: by daemon.localdomain (Postfix, from userid 21281) id CCA659B5B5; Thu, 14 Feb 2013 20:29:19 -0500 (EST) Date: Thu, 14 Feb 2013 20:29:19 -0500 From: Adam McDougall To: Rainer Duffner Subject: Re: Why does poudriere always rebuild nginx and GraphicsMagick13? Message-ID: <20130215012919.GW36563@egr.msu.edu> References: <20130212221103.GG12760@ithaqua.etoilebsd.net> <6088089D-3E61-4C82-94D4-319E48CF718B@ultra-secure.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6088089D-3E61-4C82-94D4-319E48CF718B@ultra-secure.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 01:36:53 -0000 On Fri, Feb 15, 2013 at 12:37:19AM +0100, Rainer Duffner wrote: Am 12.02.2013 um 23:11 schrieb Baptiste Daroussin : > On Tue, Feb 12, 2013 at 10:59:28PM +0100, Rainer Duffner wrote: >> Hi, >> >> poudriere 2.2 here, running on 9.1-amd64 >> >> Of the 730-ish ports, whenever I run a build, it always rebuilds the above two ports. >> Even if nothing changed. ====>> Options changed, deleting: GraphicsMagick-nox11-1.3.16_1.txz ====>> Options changed, deleting: nginx-1.2.6,1.txz Somehow, it thinks the options have changed. Maybe, the options-file has an error? Regards, Rainer Try deleting the options file for each and run poudriere twice to test. I had the same problem with mailman and it turned out I was missing a required but not enforced option due to another option I had selected. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 02:06:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A26A6939 for ; Fri, 15 Feb 2013 02:06:38 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id 5FE53AD7 for ; Fri, 15 Feb 2013 02:06:38 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 0KLB1l00i0b6N64A1S6eLS; Fri, 15 Feb 2013 02:06:38 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta03.emeryville.ca.mail.comcast.net with comcast id 0S6d1l00E1t3BNj8PS6dl3; Fri, 15 Feb 2013 02:06:38 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 27A6D73A1C; Thu, 14 Feb 2013 18:06:37 -0800 (PST) Date: Thu, 14 Feb 2013 18:06:37 -0800 From: Jeremy Chadwick To: Adam McDougall Subject: Re: Why does poudriere always rebuild nginx and GraphicsMagick13? Message-ID: <20130215020637.GA97558@icarus.home.lan> References: <20130212221103.GG12760@ithaqua.etoilebsd.net> <6088089D-3E61-4C82-94D4-319E48CF718B@ultra-secure.de> <20130215012919.GW36563@egr.msu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130215012919.GW36563@egr.msu.edu> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360893998; bh=687eqWiVP1j/GNLwhf2TrIv5HyY/ZDgd3h5rlvfWwoQ=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=s3VV8co8riRykOV29s/OhXugLcvjk+M1Fd1TwrUTpKG/MCiYE5x5GOUTDMGh+jIsj crUUB9sTivKYNzf1m2SPU7/fqfyLqp6WZCkx4cqh+peEXONmKpwZP3JaUnbRMTo28m veMJPsHiff3YXfCJJYIynwReT8dD1KVB3mcFVys1arHCqLs3J/nrnhI0rQT+OiR8mE iYSQg8rXpdZepsEotE2NDkAySXBILXdYKgmcLZj4yjZVHs63mRTmPDOn9oBD0tYmLl FB5S4p6GyDCY14giRK/B7ouKfZztSWfaqwIt8Lpg+214TKqndf/NnJLbuUHPyM5Mjz +B1MU3apTUekA== Cc: "freebsd-stable@freebsd.org" , Rainer Duffner X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Feb 2013 02:06:38 -0000 On Thu, Feb 14, 2013 at 08:29:19PM -0500, Adam McDougall wrote: > On Fri, Feb 15, 2013 at 12:37:19AM +0100, Rainer Duffner wrote: > > Am 12.02.2013 um 23:11 schrieb Baptiste Daroussin : > > > On Tue, Feb 12, 2013 at 10:59:28PM +0100, Rainer Duffner wrote: > >> Hi, > >> > >> poudriere 2.2 here, running on 9.1-amd64 > >> > >> Of the 730-ish ports, whenever I run a build, it always rebuilds the above two ports. > >> Even if nothing changed. > > ====>> Options changed, deleting: GraphicsMagick-nox11-1.3.16_1.txz > ====>> Options changed, deleting: nginx-1.2.6,1.txz > > Somehow, it thinks the options have changed. > Maybe, the options-file has an error? > > Regards, > Rainer > > Try deleting the options file for each and run poudriere twice to test. > I had the same problem with mailman and it turned out I was missing a > required but not enforced option due to another option I had selected. Note: I have no familiarity with this tool or its code. *sigh* Oh look, more shell hell... :-) Here's the code for what causes the "Options changed" logic to get called (I did not include pkg_get_options() nor pkg_cache_dir() definitions, i.e. functions used within src/poudriere.d/common.sh): 1355 # Check if the compiled options match the current options from make.conf and /var/db/options 1356 if [ "${CHECK_CHANGED_OPTIONS:-no}" != "no" ]; then 1357 current_options=$(injail make -C /usr/ports/${o} pretty-print-config | tr ' ' '\n' | sed -n 's/^\+\(.*\)/\1/p' | sort | tr '\n' ' ') 1358 compiled_options=$(pkg_get_options ${pkg}) 1359 1360 if [ "${compiled_options}" != "${current_options}" ]; then 1361 msg "Options changed, deleting: ${pkg##*/}" 1362 if [ "${CHECK_CHANGED_OPTIONS}" = "verbose" ]; then 1363 msg "Pkg: ${compiled_options}" 1364 msg "New: ${current_options}" 1365 fi 1366 delete_pkg ${pkg} 1367 return 0 1368 fi 1369 fi Note what the comment says. I have no idea what /var/db/options is, but possibly it's referring to /var/db/ports/*/options. You might try setting CHECK_CHANGED_OPTIONS=verbose (wherever it gets that from). It should print something helpful to you which you can use to work backwards. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 03:05:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CBC2BAF1; Fri, 15 Feb 2013 03:05:58 +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 546F7E11; Fri, 15 Feb 2013 03:05:57 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAKWlHVGDaFvO/2dsb2JhbABEhkm6MXOCHwEBBSMEUhsOChEZAgRVBhOIEqppkjeQcYETA4hmhi+HD5BTgyWBSyMb X-IronPort-AV: E=Sophos;i="4.84,669,1355115600"; d="scan'208";a="14197857" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 14 Feb 2013 22:05:56 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 75E6CB4031; Thu, 14 Feb 2013 22:05:56 -0500 (EST) Date: Thu, 14 Feb 2013 22:05:56 -0500 (EST) From: Rick Macklem To: Marc Fournier Message-ID: <1964289267.3041689.1360897556427.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <9A149E78-BB4F-414D-AAE5-331C5934FF82@hub.org> Subject: Re: 9-STABLE -> NFS -> NetAPP: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3041688_1205401174.1360897556425" X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Konstantin Belousov , freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 03:05:58 -0000 ------=_Part_3041688_1205401174.1360897556425 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Marc Fournier wrote: > On 2013-02-13, at 3:54 PM, Rick Macklem wrote: >=20 > >> > > The pid that is in "T" state for the "ps auxlH". >=20 > Different server, last kernel update on Jan 22nd, https process this > time instead of du last time. >=20 > I've attached: >=20 > ps auxlH > ps auxlH of just the processes that are in TJ state (6 httpd servers) > procstat output for each of the 6 process >=20 >=20 >=20 >=20 > They are included as attachments =E2=80=A6 if these don't make it through= , let > me know, just figured I'd try and keep it compact ... Well, I've looked at this call path a little closer: 16693 104135 httpd - mi_switch+0x186 thread_suspe= nd_check+0x19f sleepq_catch_signals+0x1c5 sleepq_timedwait_sig+0x19 _sleep+0x2ca clnt_vc_call+0x763 clnt_reconnect_= call+0xfb newnfs_request+0xadb nfscl_request+0x72 nfsrpc_accessrpc+0x1df nfs34_access_otw+0x56 nfs_acces= s+0x306 vn_open_cred+0x5a8 kern_openat+0x20a amd64_syscall+0x540 Xfast_syscall+0xf7=20 I am probably way off, since I am not familiar with this stuff, but it seems to me that thread_suspend_check() should just return 0 for the case where stop_allowed =3D=3D SIG_STOP_NOT_ALLOWED (TDF_SBDRY flag set) instead of sitting in the loop and doing a mi_switch(). I'm not even sure if it should call thread_suspend_check() for this case, but there are cases in thread_suspend_check() that I don't understand. Although I don't really understand thread_suspend_check(), I've attached a simple patch that might be a starting point for fixing this? I wouldn't recommend trying the patch until kib and/or jhb weigh in on whether it makes any sense. rick ------=_Part_3041688_1205401174.1360897556425 Content-Type: text/x-patch; name=sigstop.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=sigstop.patch LS0tIGtlcm4vc3Vicl9zbGVlcHF1ZXVlLmMuc2F2CTIwMTMtMDItMTQgMjA6Mzk6NDcuMDAwMDAw MDAwIC0wNTAwCisrKyBrZXJuL3N1YnJfc2xlZXBxdWV1ZS5jCTIwMTMtMDItMTQgMjE6MDM6MDMu MDAwMDAwMDAwIC0wNTAwCkBAIC00NDMsNyArNDQzLDcgQEAgc2xlZXBxX2NhdGNoX3NpZ25hbHMo dm9pZCAqd2NoYW4sIGludCBwcgogCXNpZyA9IGN1cnNpZyh0ZCwgc3RvcF9hbGxvd2VkKTsKIAlp ZiAoc2lnID09IDApIHsKIAkJbXR4X3VubG9jaygmcHMtPnBzX210eCk7Ci0JCXJldCA9IHRocmVh ZF9zdXNwZW5kX2NoZWNrKDEpOworCQlyZXQgPSB0aHJlYWRfc3VzcGVuZF9jaGVjaygxLCBzdG9w X2FsbG93ZWQpOwogCQlNUEFTUyhyZXQgPT0gMCB8fCByZXQgPT0gRUlOVFIgfHwgcmV0ID09IEVS RVNUQVJUKTsKIAl9IGVsc2UgewogCQlpZiAoU0lHSVNNRU1CRVIocHMtPnBzX3NpZ2ludHIsIHNp ZykpCi0tLSBrZXJuL2tlcm5fZXhpdC5jLnNhdgkyMDEzLTAyLTE0IDIxOjA0OjIxLjAwMDAwMDAw MCAtMDUwMAorKysga2Vybi9rZXJuX2V4aXQuYwkyMDEzLTAyLTE0IDIxOjA0OjUwLjAwMDAwMDAw MCAtMDUwMApAQCAtMTU5LDcgKzE1OSw3IEBAIGV4aXQxKHN0cnVjdCB0aHJlYWQgKnRkLCBpbnQg cnYpCiAJCSAqIEZpcnN0IGNoZWNrIGlmIHNvbWUgb3RoZXIgdGhyZWFkIGdvdCBoZXJlIGJlZm9y ZSB1cy4KIAkJICogSWYgc28sIGFjdCBhcHByb3ByaWF0ZWx5OiBleGl0IG9yIHN1c3BlbmQuCiAJ CSAqLwotCQl0aHJlYWRfc3VzcGVuZF9jaGVjaygwKTsKKwkJdGhyZWFkX3N1c3BlbmRfY2hlY2so MCwgU0lHX1NUT1BfQUxMT1dFRCk7CiAKIAkJLyoKIAkJICogS2lsbCBvZmYgdGhlIG90aGVyIHRo cmVhZHMuIFRoaXMgcmVxdWlyZXMKLS0tIGtlcm4va2Vybl9zaWcuYy5zYXYJMjAxMy0wMi0xNCAy MTowNTowNi4wMDAwMDAwMDAgLTA1MDAKKysrIGtlcm4va2Vybl9zaWcuYwkyMDEzLTAyLTE0IDIx OjA1OjQwLjAwMDAwMDAwMCAtMDUwMApAQCAtMTQ2Myw3ICsxNDYzLDcgQEAga2Vybl9zaWdzdXNw ZW5kKHN0cnVjdCB0aHJlYWQgKnRkLCBzaWdzZQogCQl3aGlsZSAobXNsZWVwKCZwLT5wX3NpZ2Fj dHMsICZwLT5wX210eCwgUFBBVVNFfFBDQVRDSCwgInBhdXNlIiwKIAkJCTApID09IDApCiAJCQkv KiB2b2lkICovOwotCQl0aHJlYWRfc3VzcGVuZF9jaGVjaygwKTsKKwkJdGhyZWFkX3N1c3BlbmRf Y2hlY2soMCwgU0lHX1NUT1BfQUxMT1dFRCk7CiAJCW10eF9sb2NrKCZwLT5wX3NpZ2FjdHMtPnBz X210eCk7CiAJCXdoaWxlICgoc2lnID0gY3Vyc2lnKHRkLCBTSUdfU1RPUF9BTExPV0VEKSkgIT0g MCkKIAkJCWhhc19zaWcgKz0gcG9zdHNpZyhzaWcpOwotLS0ga2Vybi9rZXJuX3RocmVhZC5jLnNh dgkyMDEzLTAyLTE0IDIxOjA3OjA2LjAwMDAwMDAwMCAtMDUwMAorKysga2Vybi9rZXJuX3RocmVh ZC5jCTIwMTMtMDItMTQgMjE6NDQ6MTAuMDAwMDAwMDAwIC0wNTAwCkBAIC03NjIsNyArNzYyLDcg QEAgc3RvcG1lOgogICogcmV0dXJuX2luc3RlYWQgaXMgc2V0LgogICovCiBpbnQKLXRocmVhZF9z dXNwZW5kX2NoZWNrKGludCByZXR1cm5faW5zdGVhZCkKK3RocmVhZF9zdXNwZW5kX2NoZWNrKGlu dCByZXR1cm5faW5zdGVhZCwgaW50IHN0b3BfYWxsb3dlZCkKIHsKIAlzdHJ1Y3QgdGhyZWFkICp0 ZDsKIAlzdHJ1Y3QgcHJvYyAqcDsKQEAgLTc5NCw2ICs3OTQsOSBAQCB0aHJlYWRfc3VzcGVuZF9j aGVjayhpbnQgcmV0dXJuX2luc3RlYWQpCiAJCSAgICAocC0+cF9mbGFnICYgUF9TSU5HTEVfQk9V TkRBUlkpICYmIHJldHVybl9pbnN0ZWFkKQogCQkJcmV0dXJuIChFUkVTVEFSVCk7CiAKKwkJaWYg KHN0b3BfYWxsb3dlZCA9PSBTSUdfU1RPUF9OT1RfQUxMT1dFRCAmJiByZXR1cm5faW5zdGVhZCkK KwkJCXJldHVybiAoMCk7CisKIAkJLyoKIAkJICogSWYgdGhlIHByb2Nlc3MgaXMgd2FpdGluZyBm b3IgdXMgdG8gZXhpdCwKIAkJICogdGhpcyB0aHJlYWQgc2hvdWxkIGp1c3Qgc3VpY2lkZS4KLS0t IGtlcm4vc3Vicl90cmFwLmMuc2F2CTIwMTMtMDItMTQgMjE6MDk6NDMuMDAwMDAwMDAwIC0wNTAw CisrKyBrZXJuL3N1YnJfdHJhcC5jCTIwMTMtMDItMTQgMjE6MTA6MDIuMDAwMDAwMDAwIC0wNTAw CkBAIC0yODMsNyArMjgzLDcgQEAgYXN0KHN0cnVjdCB0cmFwZnJhbWUgKmZyYW1lcCkKIAkgKi8K IAlpZiAoZmxhZ3MgJiBUREZfTkVFRFNVU1BDSEspIHsKIAkJUFJPQ19MT0NLKHApOwotCQl0aHJl YWRfc3VzcGVuZF9jaGVjaygwKTsKKwkJdGhyZWFkX3N1c3BlbmRfY2hlY2soMCwgU0lHX1NUT1Bf QUxMT1dFRCk7CiAJCVBST0NfVU5MT0NLKHApOwogCX0KIAotLS0gc3lzL3Byb2MuaC5zYXYJMjAx My0wMi0xNCAyMToxMDo1OC4wMDAwMDAwMDAgLTA1MDAKKysrIHN5cy9wcm9jLmgJMjAxMy0wMi0x NCAyMToxMjowMS4wMDAwMDAwMDAgLTA1MDAKQEAgLTk0Myw3ICs5NDMsNyBAQCB2b2lkCXRocmVh ZF9zdG9wcGVkKHN0cnVjdCBwcm9jICpwKTsKIHZvaWQJY2hpbGRwcm9jX3N0b3BwZWQoc3RydWN0 IHByb2MgKmNoaWxkLCBpbnQgcmVhc29uKTsKIHZvaWQJY2hpbGRwcm9jX2NvbnRpbnVlZChzdHJ1 Y3QgcHJvYyAqY2hpbGQpOwogdm9pZAljaGlsZHByb2NfZXhpdGVkKHN0cnVjdCBwcm9jICpjaGls ZCk7Ci1pbnQJdGhyZWFkX3N1c3BlbmRfY2hlY2soaW50IGhvdyk7CitpbnQJdGhyZWFkX3N1c3Bl bmRfY2hlY2soaW50IGhvdywgaW50IHN0b3BfYWxsb3dlZCk7CiB2b2lkCXRocmVhZF9zdXNwZW5k X3N3aXRjaChzdHJ1Y3QgdGhyZWFkICopOwogdm9pZAl0aHJlYWRfc3VzcGVuZF9vbmUoc3RydWN0 IHRocmVhZCAqdGQpOwogdm9pZAl0aHJlYWRfdW5saW5rKHN0cnVjdCB0aHJlYWQgKnRkKTsK ------=_Part_3041688_1205401174.1360897556425-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 03:08:26 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1DD47DC6; Fri, 15 Feb 2013 03:08:26 +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 B8570E41; Fri, 15 Feb 2013 03:08:25 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAKWlHVGDaFvO/2dsb2JhbABEhkm6MXOCHwEBAQQBAQEgBCcgCxsYAgINGQIpAQkmBggHBAEcBIdxDKpdkjeBI4wnDYMagRMDiGaLC4IzgR2PNoMlT34HFx4 X-IronPort-AV: E=Sophos;i="4.84,669,1355115600"; d="scan'208";a="14198053" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 14 Feb 2013 22:08:24 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id EF9C7B4165; Thu, 14 Feb 2013 22:08:24 -0500 (EST) Date: Thu, 14 Feb 2013 22:08:24 -0500 (EST) From: Rick Macklem To: "Marc G. Fournier" Message-ID: <283687726.3041739.1360897704971.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <7614F404-CD69-479E-BDFA-31451DB9040F@hub.org> Subject: Re: 9-STABLE -> NFS -> NetAPP: 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 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Konstantin Belousov , freebsd-stable@freebsd.org, Kostik Belousov , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 03:08:26 -0000 Marc Fournier wrote: > On 2013-02-14, at 16:24 , Rick Macklem wrote: >=20 > > Marc Fournier wrote: > >> On 2013-02-14, at 08:41 , Rick Macklem > >> wrote: > >> > >>> > >>> Btw Marc, if you just want this problem to go away, I suspect > >>> getting rid > >>> of the "intr" mount option would do that. > >> > >> Am more interested in fixing the problem (if possible) then just > >> masking it, but ... > >> > >> Based on the man page for mount_nfs, wouldn't that have the > >> opposite > >> effect: > >> > >> intr Make the mount interruptible, which implies that file > >> system calls that are delayed due to an unresponsive > >> server will fail with EINTR when a termination signal is > >> posted for the process. > >> > >> I may be mis-reading, but from the above it sounds like a -9 > >> *should* > >> terminate the process if intr is enabled, while with it disabled, > >> it > >> would ignore it =E2=80=A6 ? > >> > > Yes, you have misread it (or english is a wonderfully ambiguous > > thing, > > if you prefer;-). > > > > For hard mounts (which is what you get if you don't specify either > > "soft" > > nor "intr"), the RPCs behave like other I/O subsystems, which means > > they > > do non-interruptible sleeps ("D" stat in ps) waiting for server > > replies > > and continue to try and complete the RPC "forever". You can't kill > > off > > the process/thread with any signal. > > > > If "umount -f" of the filesystem works, that terminates the > > thread(s). > > Unfortunately, "umount -f" is quite broken again. I have an idea on > > how to resolve this, but I haven't coded it yet. (The problem is > > that > > the process doing "umount -f" gets stuck before it does the > > VFS_UNMOUNT(), > > so the NFS client doesn't see it.) >=20 > For how infrequently this problem generally manifests itself, is there > an overall benefit from a debugging standpoint of my leaving intr on > and reporting when it happens, including procstat output, and then > upgrading to latest kernel =E2=80=A6 ? >=20 > Its an annoyance, but it isn't like it happens daily, so I don't mind > going through the process *towards* having it fixed if there is an > overall benefit =E2=80=A6 >=20 Well, hopefully kib and/or jhb can make some progress w.r.t. this. I'll let them weigh in on what to do next, rick >=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" From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 06:51:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D54294C7 for ; Fri, 15 Feb 2013 06:51:25 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 85D7F75A for ; Fri, 15 Feb 2013 06:51:25 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.6/8.14.6) with ESMTP id r1F6pGQ2029276 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 15 Feb 2013 06:51:16 GMT (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.7.4 smtp.infracaninophile.co.uk r1F6pGQ2029276 Authentication-Results: smtp.infracaninophile.co.uk/r1F6pGQ2029276; dkim=none reason="no signature"; dkim-adsp=none (insecure policy) Message-ID: <511DDADD.9000306@FreeBSD.org> Date: Fri, 15 Feb 2013 06:51:09 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Why does poudriere always rebuild nginx and GraphicsMagick13? References: <20130212221103.GG12760@ithaqua.etoilebsd.net> <6088089D-3E61-4C82-94D4-319E48CF718B@ultra-secure.de> <62B5372A-8DD9-4352-89B0-BDEAC11A5C2C@ultra-secure.de> In-Reply-To: <62B5372A-8DD9-4352-89B0-BDEAC11A5C2C@ultra-secure.de> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2SWXRPJRDKBBNJCNWFTOO" X-Virus-Scanned: clamav-milter 0.97.6 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 06:51:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2SWXRPJRDKBBNJCNWFTOO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 15/02/2013 01:27, Rainer Duffner wrote: > OK, another issue crept up. >=20 > I started to build www/rt40 and it worked - until I updated it to the l= atest commit. > Now I get: >=20 > =3D=3D=3D=3D>> [02] Finished build of www/rt40: Ignored: please select = one of AP_MODPERL, AP_MODFASTCGI, LIGHTTPD, SPAWN_FCGI or BUILTIN >=20 >=20 > But I have: >=20 > cat /usr/local/etc/poudriere.d/91amd64-options/rt40/options > # This file is auto-generated by 'make config'. > # Options for rt-4.0.10_1 > _OPTIONS_READ=3Drt-4.0.10_1 > _FILE_COMPLETE_OPTIONS_LIST=3DDEV GD GPG GRAPHVIZ SSL_MAILGATE MYSQL OR= ACLE PGSQL SQLITE AP_MODFASTCGI AP_MODPERL LIGHTTPD SPAWN_FCGI > OPTIONS_FILE_UNSET+=3DDEV > OPTIONS_FILE_SET+=3DGD > OPTIONS_FILE_SET+=3DGPG > OPTIONS_FILE_SET+=3DGRAPHVIZ > OPTIONS_FILE_SET+=3DSSL_MAILGATE > OPTIONS_FILE_UNSET+=3DMYSQL > OPTIONS_FILE_UNSET+=3DORACLE > OPTIONS_FILE_SET+=3DPGSQL > OPTIONS_FILE_UNSET+=3DSQLITE > OPTIONS_FILE_UNSET+=3DAP_MODFASTCGI > OPTIONS_FILE_UNSET+=3DAP_MODPERL > OPTIONS_FILE_UNSET+=3DLIGHTTPD > OPTIONS_FILE_SET+=3DSPAWN_FCGI >=20 > If I run make patch in my local ports tree, with the above options file= , it runs through. >=20 >=20 > Is this a poudriere problem or more of a problem with the port itself? This part of the rt40 port -- options handling -- hasn't changed for around 6 months. My guess is that you've somehow got a mangled set of options choices somewhere where poudriere sees it. Poudriere can use a separate collection of options -- see the CUSTOMIZATION section in poudriere(8). If you want it to use the same /var/db/ports set of options as used by the ports by default, then you can make a link lie this: % ls -l /usr/local/etc/poudriere.d/options lrwxr-xr-x 1 root wheel 13 Dec 24 15:54 /usr/local/etc/poudriere.d/options@ -> /var/db/ports Or else try running: poudriere options www/rt40 to set the options poudriere will use. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey ------enig2SWXRPJRDKBBNJCNWFTOO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEd2uMACgkQ8Mjk52CukIxIfQCfWxgxgCsj+s9UlIAjXgbVV6BK AKwAn0KDqnHQ+YNu1wzH+r9sfw2CdK/n =19qt -----END PGP SIGNATURE----- ------enig2SWXRPJRDKBBNJCNWFTOO-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 10: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]) by hub.freebsd.org (Postfix) with ESMTP id 8B252AD6 for ; Fri, 15 Feb 2013 10:35:02 +0000 (UTC) (envelope-from bartsch@dssgmbh.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 41582F60 for ; Fri, 15 Feb 2013 10:35:02 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 8BF6F5E611 for ; Fri, 15 Feb 2013 11:26:15 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id QdqoDNrnNifh for ; Fri, 15 Feb 2013 11:26:11 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 918415E60C for ; Fri, 15 Feb 2013 11:26:11 +0100 (CET) Received: from pcadmin.incore (pcadmin.incore [192.168.0.140]) by mail.incore (Postfix) with ESMTPSA id 8A3C050857 for ; Fri, 15 Feb 2013 11:26:11 +0100 (CET) Message-ID: <511E0D43.6070900@dssgmbh.de> Date: Fri, 15 Feb 2013 11:26:11 +0100 From: Alfred Bartsch User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org Subject: some issues with /usr/sbin/service X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 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, 15 Feb 2013 10:35:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, we want to use this script for server administration purposes. After doing some testing, for now there are following issues left: 1) every execution of "service -e" casts a bunch of unnecessary warnings into /var/log/messages: "... /usr/sbin/service: WARNING: $_enable is not set properly - see rc.conf(5)." This is caused by calling "checkyesno()", provided by /etc/subr. It could be solved by using a local function, named "checkyes" or similar. The following patch prohibits these annoying messages: - --- service.orig 2013-02-10 20:01:14.000000000 +0100 +++ service 2013-02-15 08:51:30.000000000 +0100 @@ -28,6 +28,28 @@ . /etc/rc.subr load_rc_config 'XXX' +# +# checkyes var +# Test $1 variable. +# Return 0 if it's "yes" (et al), nonzero otherwise. +# +checkyes() +{ + eval _value=\$${1} + debug "checkyes: $1 is set to $_value." + case $_value in + + # "yes", "true", "on", or "1" + [Yy][Ee][Ss]|[Tt][Rr][Uu][Ee]|[Oo][Nn]|1) + return 0 + ;; + + # everything else + *) + return 1 + ;; + esac +} usage () { echo '' @@ -100,7 +122,7 @@ if grep -q ^rcvar $file; then eval `grep ^name= $file` eval `grep ^rcvar $file` - - checkyesno $rcvar 2>/dev/null && echo $file + checkyes $rcvar 2>/dev/null && echo $file fi done exit 0 2) "service -e" does not show ALL enabled services, but only those who are explicitly enabled in /etc/defaults/rc.conf or /etc/rc.conf. Is that expected behavior? To catch all enabled services where the _enabled variable is set within the service procedure itself, perhaps a call like "service status" could help. - -- Regards Alfred Bartsch Data-Service GmbH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEeDUMACgkQ5QGe2JdVf3hL5QCggTK3JP9A+ZybIX/iCsuqu5Ic bYQAn2w7Y2klRoEy7ithoxeVcl4xA2be =QJmh -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 10:57:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ED4E3396 for ; Fri, 15 Feb 2013 10:57:13 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by mx1.freebsd.org (Postfix) with ESMTP id B737B137 for ; Fri, 15 Feb 2013 10:57:13 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta07.emeryville.ca.mail.comcast.net with comcast id 0aw81l0031Y3wxoA7axBRH; Fri, 15 Feb 2013 10:57:11 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta15.emeryville.ca.mail.comcast.net with comcast id 0axA1l00M1t3BNj8baxBsj; Fri, 15 Feb 2013 10:57:11 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id ADDE073A1C; Fri, 15 Feb 2013 02:57:10 -0800 (PST) Date: Fri, 15 Feb 2013 02:57:10 -0800 From: Jeremy Chadwick To: Alfred Bartsch Subject: Re: some issues with /usr/sbin/service Message-ID: <20130215105710.GA6130@icarus.home.lan> References: <511E0D43.6070900@dssgmbh.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <511E0D43.6070900@dssgmbh.de> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360925831; bh=xYVjahJf+ynRDVEWPQh+z7Ubn19h9dJoBRcExxL6W9I=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=QvyOvIcSbnKgGEof4mvfU7OHzNRZzh9ZzF1RqGB8aHnruPIkuv6ax1JBwm8DXO6LQ s2CwId04tswGe2jcJpeXIXTmaBhdRMvpoGCKcgTUeuwZVP74+8bG9kA7M7qanA+02E IjwVYG93OMF9TDR2MD1yFn80D7A1aIqgz9kN4LpMKR4uSmSsMaMov5qfKyXcTwHB8Q wuOUjEHNgf8BHIaWRTdI9wq1C6nTzL9z0UMacJhzPpxRXZrWHBNp2aovXiaogGcq3E yUB2xiFOyIBVrHCmDprygppLk12lQ29QfEG3/lx9BozHmhqVbPtp6t7H04kF9Syi07 w3nVZje0WOFbQ== 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, 15 Feb 2013 10:57:14 -0000 On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote: > we want to use this script for server administration purposes. After > doing some testing, for now there are following issues left: > > 1) every execution of "service -e" casts a bunch of unnecessary > warnings into /var/log/messages: > "... /usr/sbin/service: WARNING: $_enable is not set > properly - see rc.conf(5)." > This is caused by calling "checkyesno()", provided by /etc/subr. It > could be solved by using a local function, named "checkyes" or similar. > > The following patch prohibits these annoying messages: > {snip} Your patch, in effectively, "rewrites" checkyesno() to remove the warn() call in cases where xxx_enable variables are set to values other than yes/true/on/1 or no/false/off/0. Here's a better idea: Fix your /etc/rc.conf xxx_enable variables which contain values that aren't permitted. That's what the warn() is for -- to tell you to fix them. :-) If there are ports (or worse, rc.d scripts) out there which recommend xxx_enable variables with non-permitted values, then these ports need to be fixed, not rc.subr(8) nor service(8). Please disclose what those are so they can be fixed. However, "service -e" does not emit warnings on my 2 systems: root@icarus:~ # service -e /etc/rc.d/hostid /etc/rc.d/zvol /etc/rc.d/ddb /etc/rc.d/hostid_save /etc/rc.d/zfs /etc/rc.d/cleanvar /etc/rc.d/ip6addrctl /etc/rc.d/devd /etc/rc.d/netwait /etc/rc.d/newsyslog /etc/rc.d/syslogd /etc/rc.d/named /etc/rc.d/ntpdate /etc/rc.d/dmesg /etc/rc.d/virecover /etc/rc.d/motd /etc/rc.d/ntpd /etc/rc.d/powerd /usr/local/etc/rc.d/samba /usr/local/etc/rc.d/postfix /usr/local/etc/rc.d/mysql-server /usr/local/etc/rc.d/apache22 /etc/rc.d/sshd /etc/rc.d/cron /etc/rc.d/mixer /etc/rc.d/inetd /etc/rc.d/gptboot root@omake:~ # service -e /etc/rc.d/hostid /etc/rc.d/ddb /etc/rc.d/hostid_save /etc/rc.d/cleanvar /etc/rc.d/ip6addrctl /etc/rc.d/devd /etc/rc.d/pflog /etc/rc.d/pf /etc/rc.d/netwait /etc/rc.d/newsyslog /etc/rc.d/syslogd /etc/rc.d/named /etc/rc.d/ntpdate /etc/rc.d/dmesg /etc/rc.d/virecover /etc/rc.d/motd /etc/rc.d/ntpd /usr/local/etc/rc.d/sa-spamd /usr/local/etc/rc.d/postfix /usr/local/etc/rc.d/dovecot /usr/local/etc/rc.d/apache22 /etc/rc.d/sshd /etc/rc.d/cron /etc/rc.d/mixer /etc/rc.d/inetd /etc/rc.d/gptboot Regardless: the permitted values (see above) should be documented in rc.conf(5) somewhere; I don't see any values other than "yes" documented, but I'm probably overlooking it. > 2) "service -e" does not show ALL enabled services, but only those who > are explicitly enabled in /etc/defaults/rc.conf or /etc/rc.conf. > Is that expected behavior? It is the expected behaviour as I understand it per the man page. You should also see rc(8). As I understand it, an "enabled service" is not a process that's running, but something that has a yes/true/on/1 value for its xxx_enabled variable in rc.conf/related file. That's just how it works. If you're used to, for example, Solaris "svcs" then yes things are different here. > To catch all enabled services where the _enabled variable is set > within the service procedure itself, perhaps a call like "service > status" could help. There is already "service status". See rc(8) (search for "status") or try it yourself on a running service. Example: root@icarus:~ # service postfix status postfix is running as pid 1378. Can you rephrase or give an example of what you want? -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 13:47:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B976270C for ; Fri, 15 Feb 2013 13:47:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 88224CE6 for ; Fri, 15 Feb 2013 13:47:40 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E7A93B94B; Fri, 15 Feb 2013 08:47:39 -0500 (EST) From: John Baldwin To: Rick Macklem Subject: Re: 9-STABLE -> NFS -> NetAPP: Date: Fri, 15 Feb 2013 08:44:43 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <1964289267.3041689.1360897556427.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1964289267.3041689.1360897556427.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201302150844.43188.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 15 Feb 2013 08:47:40 -0500 (EST) Cc: Marc Fournier , Konstantin Belousov , 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, 15 Feb 2013 13:47:40 -0000 On Thursday, February 14, 2013 10:05:56 pm Rick Macklem wrote: > Marc Fournier wrote: > > On 2013-02-13, at 3:54 PM, Rick Macklem wrote: > >=20 > > >> > > > The pid that is in "T" state for the "ps auxlH". > >=20 > > Different server, last kernel update on Jan 22nd, https process this > > time instead of du last time. > >=20 > > I've attached: > >=20 > > ps auxlH > > ps auxlH of just the processes that are in TJ state (6 httpd servers) > > procstat output for each of the 6 process > >=20 > >=20 > >=20 > >=20 > > They are included as attachments =E2=80=A6 if these don't make it throu= gh, let > > me know, just figured I'd try and keep it compact ... > Well, I've looked at this call path a little closer: > 16693 104135 httpd - mi_switch+0x186=20 thread_suspend_check+0x19f sleepq_catch_signals+0x1c5 > sleepq_timedwait_sig+0x19 _sleep+0x2ca clnt_vc_call+0x763=20 clnt_reconnect_call+0xfb newnfs_request+0xadb > nfscl_request+0x72 nfsrpc_accessrpc+0x1df nfs34_access_otw+0x56=20 nfs_access+0x306 vn_open_cred+0x5a8 > kern_openat+0x20a amd64_syscall+0x540 Xfast_syscall+0xf7=20 >=20 > I am probably way off, since I am not familiar with this stuff, but it > seems to me that thread_suspend_check() should just return 0 for the > case where stop_allowed =3D=3D SIG_STOP_NOT_ALLOWED (TDF_SBDRY flag set) > instead of sitting in the loop and doing a mi_switch(). I'm not even > sure if it should call thread_suspend_check() for this case, but there > are cases in thread_suspend_check() that I don't understand. >=20 > Although I don't really understand thread_suspend_check(), I've attached > a simple patch that might be a starting point for fixing this? >=20 > I wouldn't recommend trying the patch until kib and/or jhb weigh in > on whether it makes any sense. I think this is the right idea, but in HEAD with the sigdeferstop() changes= it=20 should just check for TDF_SBDRY instead of adding a new parameter. I think checking for TDF_SBDRY will work even in 9 (and will make the patch smaller= ). =20 Also, I think this is only needed for stop signals. Other suspend requests= =20 will eventually resume the thread, it is only stop signals that can cause t= he=20 thread to get stuck indefinitely (since it depends on the user sending=20 SIGCONT). Marc, are you using SIGSTOP? Index: kern_thread.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D-- kern_thread.c (revision 246122) +++ kern_thread.c (working copy) @@ -795,6 +795,17 @@ thread_suspend_check(int return_instead) return (ERESTART); =20 /* + * Ignore suspend requests for stop signals if they + * are deferred. + */ + if (P_SHOULDSTOP(p) =3D=3D P_STOPPED_SIG && + td->td_flags & TDF_SBDRY) { + KASSERT(return_instead, + ("TDF_SBDRY set for unsafe thread_suspend_check")); + return (0); + } + + /* * If the process is waiting for us to exit, * this thread should just suicide. * Assumes that P_SINGLE_EXIT implies P_STOPPED_SINGLE. =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 13:52: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]) by hub.freebsd.org (Postfix) with ESMTP id F3184982 for ; Fri, 15 Feb 2013 13:51:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id CA64FD69 for ; Fri, 15 Feb 2013 13:51:59 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 50E71B94B; Fri, 15 Feb 2013 08:51:58 -0500 (EST) From: John Baldwin To: "Mikhail T." Subject: Re: FreeBSD-9.1 would not boot on pentium3 laptop Date: Fri, 15 Feb 2013 08:49:29 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <5111DE44.7040008@aldan.algebra.com> <5113F24E.3070207@aldan.algebra.com> <201302071425.17064.jhb@freebsd.org> In-Reply-To: <201302071425.17064.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302150849.29085.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 15 Feb 2013 08:51:58 -0500 (EST) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 13:52:00 -0000 On Thursday, February 07, 2013 2:25:17 pm John Baldwin wrote: > On Thursday, February 07, 2013 1:28:30 pm Mikhail T. wrote: > > On 07.02.2013 13:16, John Baldwin wrote: > > > Can you get pciconf -lc output? > > Here: > > > > hostb0@pci0:0:0:0: class=0x060000 card=0x00000000 > > chip=0x11308086 rev=0x02 hdr=0x00 > > cap 09[88] = vendor (length 4) Intel cap 15 version 1 > > cap 02[a0] = AGP 4x 2x 1x SBA disabled > > Looks like you have one of the systems the comment mentions. Try this patch > to see if ichss is disabled automatically for you: Were you able to test this patch? > Index: ichss.c > =================================================================== > --- ichss.c (revision 246122) > +++ ichss.c (working copy) > @@ -67,7 +67,7 @@ struct ichss_softc { > #define PCI_DEV_82801BA 0x244c /* ICH2M */ > #define PCI_DEV_82801CA 0x248c /* ICH3M */ > #define PCI_DEV_82801DB 0x24cc /* ICH4M */ > -#define PCI_DEV_82815BA 0x1130 /* Unsupported/buggy part */ > +#define PCI_DEV_82815_MC 0x1130 /* Unsupported/buggy part */ > > /* PCI config registers for finding PMBASE and enabling SpeedStep. */ > #define ICHSS_PMBASE_OFFSET 0x40 > @@ -155,9 +155,6 @@ ichss_identify(driver_t *driver, device_t parent) > * E.g. see Section 6.1 "PCI Devices and Functions" and table 6.1 of > * Intel(r) 82801BA I/O Controller Hub 2 (ICH2) and Intel(r) 82801BAM > * I/O Controller Hub 2 Mobile (ICH2-M). > - * > - * TODO: add a quirk to disable if we see the 82815_MC along > - * with the 82801BA and revision < 5. > */ > ich_device = pci_find_bsf(0, 0x1f, 0); > if (ich_device == NULL || > @@ -167,6 +164,22 @@ ichss_identify(driver_t *driver, device_t parent) > pci_get_device(ich_device) != PCI_DEV_82801DB)) > return; > > + /* > + * Certain systems with ICH2 and an Intel 82815_MC host bridge > + * where the host bridge's revision is < 5 lockup if SpeedStep > + * is used. > + */ > + if (pci_get_device(ich_device) == PCI_DEV_82801BA) { > + device_t hostb; > + > + hostb = pci_find_bsf(0, 0, 0); > + if (hostb != NULL && > + pci_get_vendor(hostb) == PCI_VENDOR_INTEL && > + pci_get_device(hostb) == PCI_DEV_82815_MC && > + pci_get_revid(hostb) < 5) > + return; > + } > + > /* Find the PMBASE register from our PCI config header. */ > pmbase = pci_read_config(ich_device, ICHSS_PMBASE_OFFSET, > sizeof(pmbase)); > -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 13:52:14 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 59E8AA96; Fri, 15 Feb 2013 13:52:14 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by mx1.freebsd.org (Postfix) with ESMTP id 14514D6C; Fri, 15 Feb 2013 13:52:13 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id h2so3695126oag.24 for ; Fri, 15 Feb 2013 05:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; bh=UaI7Jzc+2KFBVM/j4Qqr+vA9RqAhfLV2tkuScg1YcF8=; b=c3zqNqkvicDDVSdRFC7/GTdKNrLv0++Gh+75ZoioZiRqRkSkulv6U1pXM+DgMv51rR JLAodDDg34tcZbABaE/PKeqB8VYJivHkhxqe+JT9OGtwXsrzeymeHCi9UCMd/2D0AtkJ MU33J5TFC7H0CllwKEvtNoBbQt/ltx6kOgGa91kEZKT1Z+JWJddG4U+pKwYZ65Ut+R3R vuiuyuHBUIebNn5SN0vkFhtjKGM7qJzVQsi0xOBz/dxoHOJ8AB2bdxBMJZtvefi4GWD8 bAf7bDFNM4jtcScin1VQNyROCzH0ph3wvYCEj3buK7Fj6YwS9vRmPl22oweBWZzZ1/vZ q84Q== MIME-Version: 1.0 X-Received: by 10.60.172.163 with SMTP id bd3mr1511014oec.78.1360936333313; Fri, 15 Feb 2013 05:52:13 -0800 (PST) Sender: pali.gabor@gmail.com Received: by 10.182.87.195 with HTTP; Fri, 15 Feb 2013 05:52:13 -0800 (PST) Date: Fri, 15 Feb 2013 14:52:13 +0100 X-Google-Sender-Auth: 89HnZh7YfTvDtvGbu5SG508aZ0U Message-ID: Subject: Final Reminder: FreeBSD Quarterly Status Reports, July--December, 2012 From: Gabor Pali To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, 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: Fri, 15 Feb 2013 13:52:14 -0000 Hello there, Just a final reminder: the deadline for the reports is this Sunday. On Sun, Feb 10, 2013 at 3:42 PM, Gabor Pali wrote: > Let me call your attention to the approaching deadline of the next > set(s) of FreeBSD Quarterly Status Reports. Please consider > submitting a few lines on your FreeBSD-related project, we are > counting on all of you! :-) > > On Sun, Jan 13, 2013 at 10:57 PM, Gabor Pali wrote: >> Please note that the deadline for submissions covering the period >> between July and December 2012 is February 17th, 2013. > > You can find more details on submission at the Project's web site [1] > but you are free to ask me directly (in private) if you need help with > this. > > [1] http://www.freebsd.org/news/status/ From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 14:21:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5A8A8D3A; Fri, 15 Feb 2013 14:21:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id AAAE7F13; Fri, 15 Feb 2013 14:21:04 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1FEKwSA040771; Fri, 15 Feb 2013 16:20:58 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1FEKwSA040771 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1FEKwPN040770; Fri, 15 Feb 2013 16:20:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 15 Feb 2013 16:20:58 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: 9-STABLE -> NFS -> NetAPP: Message-ID: <20130215142058.GP2522@kib.kiev.ua> References: <1964289267.3041689.1360897556427.JavaMail.root@erie.cs.uoguelph.ca> <201302150844.43188.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x6xK9fUDGUdTBgu/" Content-Disposition: inline In-Reply-To: <201302150844.43188.jhb@freebsd.org> 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: Marc Fournier , Rick Macklem , 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, 15 Feb 2013 14:21:05 -0000 --x6xK9fUDGUdTBgu/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 15, 2013 at 08:44:43AM -0500, John Baldwin wrote: > On Thursday, February 14, 2013 10:05:56 pm Rick Macklem wrote: > > Marc Fournier wrote: > > > On 2013-02-13, at 3:54 PM, Rick Macklem wrote: > > >=20 > > > >> > > > > The pid that is in "T" state for the "ps auxlH". > > >=20 > > > Different server, last kernel update on Jan 22nd, https process this > > > time instead of du last time. > > >=20 > > > I've attached: > > >=20 > > > ps auxlH > > > ps auxlH of just the processes that are in TJ state (6 httpd servers) > > > procstat output for each of the 6 process > > >=20 > > >=20 > > >=20 > > >=20 > > > They are included as attachments ??? if these don't make it through, = let > > > me know, just figured I'd try and keep it compact ... > > Well, I've looked at this call path a little closer: > > 16693 104135 httpd - mi_switch+0x186=20 > thread_suspend_check+0x19f sleepq_catch_signals+0x1c5 > > sleepq_timedwait_sig+0x19 _sleep+0x2ca clnt_vc_call+0x763=20 > clnt_reconnect_call+0xfb newnfs_request+0xadb > > nfscl_request+0x72 nfsrpc_accessrpc+0x1df nfs34_access_otw+0x56=20 > nfs_access+0x306 vn_open_cred+0x5a8 > > kern_openat+0x20a amd64_syscall+0x540 Xfast_syscall+0xf7=20 > >=20 > > I am probably way off, since I am not familiar with this stuff, but it > > seems to me that thread_suspend_check() should just return 0 for the > > case where stop_allowed =3D=3D SIG_STOP_NOT_ALLOWED (TDF_SBDRY flag set) > > instead of sitting in the loop and doing a mi_switch(). I'm not even > > sure if it should call thread_suspend_check() for this case, but there > > are cases in thread_suspend_check() that I don't understand. > >=20 > > Although I don't really understand thread_suspend_check(), I've attached > > a simple patch that might be a starting point for fixing this? > >=20 > > I wouldn't recommend trying the patch until kib and/or jhb weigh in > > on whether it makes any sense. >=20 > I think this is the right idea, but in HEAD with the sigdeferstop() chang= es it=20 > should just check for TDF_SBDRY instead of adding a new parameter. I thi= nk > checking for TDF_SBDRY will work even in 9 (and will make the patch small= er). =20 > Also, I think this is only needed for stop signals. Other suspend reques= ts=20 > will eventually resume the thread, it is only stop signals that can cause= the=20 > thread to get stuck indefinitely (since it depends on the user sending=20 > SIGCONT). >=20 > Marc, are you using SIGSTOP? >=20 > Index: kern_thread.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- kern_thread.c (revision 246122) > +++ kern_thread.c (working copy) > @@ -795,6 +795,17 @@ thread_suspend_check(int return_instead) > return (ERESTART); > =20 > /* > + * Ignore suspend requests for stop signals if they > + * are deferred. > + */ > + if (P_SHOULDSTOP(p) =3D=3D P_STOPPED_SIG && > + td->td_flags & TDF_SBDRY) { > + KASSERT(return_instead, > + ("TDF_SBDRY set for unsafe thread_suspend_check")); > + return (0); > + } > + > + /* > * If the process is waiting for us to exit, > * this thread should just suicide. > * Assumes that P_SINGLE_EXIT implies P_STOPPED_SINGLE. This looks correct. --x6xK9fUDGUdTBgu/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRHkRKAAoJEJDCuSvBvK1BhqcP/1ZMeeY09CIL6iaas1h7ZNbS C3Mli28bNxVuvxTs9GhDUNm0XxKjAmQtAFzV8m+DFC1TfYBqr++0OT1lXlFcclrV 9bCN7qFi/iWvW08FT2xkjb531oRYdkWe7T5fSDb36RhYEvmxRdy3aefojls8rJTf CBaggYsKTcV0XXabrJnaeZcvm1JLoL2cbvy9CR1MExrn40JqWEOkxkK/PuhCGU46 rAxOrNdbequrvdMQrwoNOrX8H/e+O8pm6Ze2O2QkxMAKXQhFc02vNi3nlNRC8P6f 2vXp1GN6W+sWHh+QkUEI++lwiR8w2B8101DVQInyJhexGMCYtoBMBw9TsH4kwouG nPwHQ6wUc6bhILT9qZUd8Ebx7zTIpTjPT63wsImo6uJD+g19UirwMHbb2OKo1Tao NeItzu831RFmGGuwIGzQFkOjGXlYLbFKV5I4F0pVAJcSG5msPpZOz5GLdEToMLMO w58qTu2vB0UOlAek6XivlZe7+wFsKYgDP/Q/+9G53ZEXEjHLCeqQG/xeA19Gz+T2 M4xoNGSCFWJ2BXJ6TjOYC9z0paxIFiAhApnxNgubcxo97gx+51RDRVzxr7vE1Bca W6OazVjcP3pLvQbtU+QWwe09xP/CchahfdSdClchZRItG71kMm+FQzR9fl3HFQKX 6qPRrdT3hpYSnmYSSLHP =zQlJ -----END PGP SIGNATURE----- --x6xK9fUDGUdTBgu/-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 15:21:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1A1E784F; Fri, 15 Feb 2013 15:21:31 +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 A5BB8272; Fri, 15 Feb 2013 15:21:30 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAAlSHlGDaFvO/2dsb2JhbABEhkm5JoERc4IfAQEFIwRSGw4KAgINGQJZBhOIEqpyki+BI41UATMHgi2BEwOIZo1CkFWDJYFLIxs X-IronPort-AV: E=Sophos;i="4.84,674,1355115600"; d="scan'208";a="16833562" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 15 Feb 2013 10:21:11 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B3652B3F43; Fri, 15 Feb 2013 10:21:11 -0500 (EST) Date: Fri, 15 Feb 2013 10:21:11 -0500 (EST) From: Rick Macklem To: Konstantin Belousov Message-ID: <860054725.3050415.1360941671689.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20130215142058.GP2522@kib.kiev.ua> Subject: Re: 9-STABLE -> NFS -> NetAPP: 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 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Marc Fournier , freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 15:21:31 -0000 Konstantin Belousov wrote: > On Fri, Feb 15, 2013 at 08:44:43AM -0500, John Baldwin wrote: > > On Thursday, February 14, 2013 10:05:56 pm Rick Macklem wrote: > > > Marc Fournier wrote: > > > > On 2013-02-13, at 3:54 PM, Rick Macklem > > > > wrote: > > > > > > > > >> > > > > > The pid that is in "T" state for the "ps auxlH". > > > > > > > > Different server, last kernel update on Jan 22nd, https process > > > > this > > > > time instead of du last time. > > > > > > > > I've attached: > > > > > > > > ps auxlH > > > > ps auxlH of just the processes that are in TJ state (6 httpd > > > > servers) > > > > procstat output for each of the 6 process > > > > > > > > > > > > > > > > > > > > They are included as attachments ??? if these don't make it > > > > through, let > > > > me know, just figured I'd try and keep it compact ... > > > Well, I've looked at this call path a little closer: > > > 16693 104135 httpd - mi_switch+0x186 > > thread_suspend_check+0x19f sleepq_catch_signals+0x1c5 > > > sleepq_timedwait_sig+0x19 _sleep+0x2ca clnt_vc_call+0x763 > > clnt_reconnect_call+0xfb newnfs_request+0xadb > > > nfscl_request+0x72 nfsrpc_accessrpc+0x1df nfs34_access_otw+0x56 > > nfs_access+0x306 vn_open_cred+0x5a8 > > > kern_openat+0x20a amd64_syscall+0x540 Xfast_syscall+0xf7 > > > > > > I am probably way off, since I am not familiar with this stuff, > > > but it > > > seems to me that thread_suspend_check() should just return 0 for > > > the > > > case where stop_allowed == SIG_STOP_NOT_ALLOWED (TDF_SBDRY flag > > > set) > > > instead of sitting in the loop and doing a mi_switch(). I'm not > > > even > > > sure if it should call thread_suspend_check() for this case, but > > > there > > > are cases in thread_suspend_check() that I don't understand. > > > > > > Although I don't really understand thread_suspend_check(), I've > > > attached > > > a simple patch that might be a starting point for fixing this? > > > > > > I wouldn't recommend trying the patch until kib and/or jhb weigh > > > in > > > on whether it makes any sense. > > > > I think this is the right idea, but in HEAD with the sigdeferstop() > > changes it > > should just check for TDF_SBDRY instead of adding a new parameter. I > > think > > checking for TDF_SBDRY will work even in 9 (and will make the patch > > smaller). > > Also, I think this is only needed for stop signals. Other suspend > > requests > > will eventually resume the thread, it is only stop signals that can > > cause the > > thread to get stuck indefinitely (since it depends on the user > > sending > > SIGCONT). > > > > Marc, are you using SIGSTOP? > > > > Index: kern_thread.c > > =================================================================== > > --- kern_thread.c (revision 246122) > > +++ kern_thread.c (working copy) > > @@ -795,6 +795,17 @@ thread_suspend_check(int return_instead) > > return (ERESTART); > > > > /* > > + * Ignore suspend requests for stop signals if they > > + * are deferred. > > + */ > > + if (P_SHOULDSTOP(p) == P_STOPPED_SIG && > > + td->td_flags & TDF_SBDRY) { > > + KASSERT(return_instead, > > + ("TDF_SBDRY set for unsafe thread_suspend_check")); > > + return (0); > > + } > > + > > + /* > > * If the process is waiting for us to exit, > > * this thread should just suicide. > > * Assumes that P_SINGLE_EXIT implies P_STOPPED_SINGLE. > > This looks correct. Righto. Thanks jhb and kib for looking at this. Btw John, PBDRY still gets set for sleeps in the sys/rpc code. However, as far as I can tell, it just sets TDF_SBDRY when it is already set and seems harmless. (Since this code is supposed to be generic and not specific to NFS, maybe it should stay that way?) Also, since PBDRY on the sleeps sets TDF_SBDRY, I think the above patch is ok for stable/9 without your recent head patch. Maybe Marc can test the above patch? Thanks everyone for your help, rick From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 15:36:54 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 50CE5CE3 for ; Fri, 15 Feb 2013 15:36:54 +0000 (UTC) (envelope-from kurt.lidl@cello.com) Received: from Mail.Fairview-Park.Com (Mail.Fairview-Park.Com [98.141.206.6]) by mx1.freebsd.org (Postfix) with ESMTP id E35992F2 for ; Fri, 15 Feb 2013 15:36:53 +0000 (UTC) Received: from [192.168.8.101] (Kurt.Fairview-Park.Com [192.168.8.101]) (authenticated bits=0) by Mail.Fairview-Park.Com (8.14.5/8.14.5) with ESMTP id r1FFalEO035499 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 15 Feb 2013 10:36:47 -0500 (EST) (envelope-from kurt.lidl@cello.com) X-FVP-rcvd: Kurt.Fairview-Park.Com [192.168.8.101] Fri, 15 Feb 2013 10:36:47 -0500 (EST) Message-ID: <511E5622.3050905@cello.com> Date: Fri, 15 Feb 2013 10:37:06 -0500 From: Kurt Lidl User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Ipsec VPN tunnel from a Win/7 box? References: <511D3E56.9060103@denninger.net> In-Reply-To: <511D3E56.9060103@denninger.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 15:36:54 -0000 Hmm. I've got IPSEC tunnels from Windows XP and Windows 7 working to a FreeBSD 8.3 host, using NAT/T. I'm using the Shrewsoft client: http://www.shrew.net/software -Kurt From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 15:45:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2454AED2 for ; Fri, 15 Feb 2013 15:45:58 +0000 (UTC) (envelope-from karl@denninger.net) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id DAE40359 for ; Fri, 15 Feb 2013 15:45:57 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.6/8.13.1) with ESMTP id r1FFjuKQ034502 for ; Fri, 15 Feb 2013 09:45:56 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Fri Feb 15 09:45:56 2013 Message-ID: <511E582E.4030408@denninger.net> Date: Fri, 15 Feb 2013 09:45:50 -0600 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Ipsec VPN tunnel from a Win/7 box? References: <511D3E56.9060103@denninger.net> <511E5622.3050905@cello.com> In-Reply-To: <511E5622.3050905@cello.com> X-Enigmail-Version: 1.5 X-Antivirus: avast! (VPS 130215-0, 02/15/2013), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 15:45:58 -0000 On 2/15/2013 9:37 AM, Kurt Lidl wrote: > > Hmm. > > I've got IPSEC tunnels from Windows XP and Windows 7 working > to a FreeBSD 8.3 host, using NAT/T. > > I'm using the Shrewsoft client: http://www.shrew.net/software > > -Kurt > _________________ The goal is to do it using only the native Win/7 VPN support. So far I've failed for IPSEC :-) -- -- Karl Denninger /The Market Ticker ®/ Cuda Systems LLC From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 15:52:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 457843AF for ; Fri, 15 Feb 2013 15:52:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E91143E3 for ; Fri, 15 Feb 2013 15:52:20 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 42354B93E; Fri, 15 Feb 2013 10:52:20 -0500 (EST) From: John Baldwin To: Rick Macklem Subject: Re: 9-STABLE -> NFS -> NetAPP: Date: Fri, 15 Feb 2013 10:26:41 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <860054725.3050415.1360941671689.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <860054725.3050415.1360941671689.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201302151026.41638.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 15 Feb 2013 10:52:20 -0500 (EST) Cc: Konstantin Belousov , Marc Fournier , 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, 15 Feb 2013 15:52:21 -0000 On Friday, February 15, 2013 10:21:11 am Rick Macklem wrote: > Konstantin Belousov wrote: > > On Fri, Feb 15, 2013 at 08:44:43AM -0500, John Baldwin wrote: > > > On Thursday, February 14, 2013 10:05:56 pm Rick Macklem wrote: > > > > Marc Fournier wrote: > > > > > On 2013-02-13, at 3:54 PM, Rick Macklem > > > > > wrote: > > > > > > > > > > >> > > > > > > The pid that is in "T" state for the "ps auxlH". > > > > > > > > > > Different server, last kernel update on Jan 22nd, https process > > > > > this > > > > > time instead of du last time. > > > > > > > > > > I've attached: > > > > > > > > > > ps auxlH > > > > > ps auxlH of just the processes that are in TJ state (6 httpd > > > > > servers) > > > > > procstat output for each of the 6 process > > > > > > > > > > > > > > > > > > > > > > > > > They are included as attachments ??? if these don't make it > > > > > through, let > > > > > me know, just figured I'd try and keep it compact ... > > > > Well, I've looked at this call path a little closer: > > > > 16693 104135 httpd - mi_switch+0x186 > > > thread_suspend_check+0x19f sleepq_catch_signals+0x1c5 > > > > sleepq_timedwait_sig+0x19 _sleep+0x2ca clnt_vc_call+0x763 > > > clnt_reconnect_call+0xfb newnfs_request+0xadb > > > > nfscl_request+0x72 nfsrpc_accessrpc+0x1df nfs34_access_otw+0x56 > > > nfs_access+0x306 vn_open_cred+0x5a8 > > > > kern_openat+0x20a amd64_syscall+0x540 Xfast_syscall+0xf7 > > > > > > > > I am probably way off, since I am not familiar with this stuff, > > > > but it > > > > seems to me that thread_suspend_check() should just return 0 for > > > > the > > > > case where stop_allowed == SIG_STOP_NOT_ALLOWED (TDF_SBDRY flag > > > > set) > > > > instead of sitting in the loop and doing a mi_switch(). I'm not > > > > even > > > > sure if it should call thread_suspend_check() for this case, but > > > > there > > > > are cases in thread_suspend_check() that I don't understand. > > > > > > > > Although I don't really understand thread_suspend_check(), I've > > > > attached > > > > a simple patch that might be a starting point for fixing this? > > > > > > > > I wouldn't recommend trying the patch until kib and/or jhb weigh > > > > in > > > > on whether it makes any sense. > > > > > > I think this is the right idea, but in HEAD with the sigdeferstop() > > > changes it > > > should just check for TDF_SBDRY instead of adding a new parameter. I > > > think > > > checking for TDF_SBDRY will work even in 9 (and will make the patch > > > smaller). > > > Also, I think this is only needed for stop signals. Other suspend > > > requests > > > will eventually resume the thread, it is only stop signals that can > > > cause the > > > thread to get stuck indefinitely (since it depends on the user > > > sending > > > SIGCONT). > > > > > > Marc, are you using SIGSTOP? > > > > > > Index: kern_thread.c > > > =================================================================== > > > --- kern_thread.c (revision 246122) > > > +++ kern_thread.c (working copy) > > > @@ -795,6 +795,17 @@ thread_suspend_check(int return_instead) > > > return (ERESTART); > > > > > > /* > > > + * Ignore suspend requests for stop signals if they > > > + * are deferred. > > > + */ > > > + if (P_SHOULDSTOP(p) == P_STOPPED_SIG && > > > + td->td_flags & TDF_SBDRY) { > > > + KASSERT(return_instead, > > > + ("TDF_SBDRY set for unsafe thread_suspend_check")); > > > + return (0); > > > + } > > > + > > > + /* > > > * If the process is waiting for us to exit, > > > * this thread should just suicide. > > > * Assumes that P_SINGLE_EXIT implies P_STOPPED_SINGLE. > > > > This looks correct. > Righto. Thanks jhb and kib for looking at this. > > Btw John, PBDRY still gets set for sleeps in the sys/rpc code. However, > as far as I can tell, it just sets TDF_SBDRY when it is already set > and seems harmless. (Since this code is supposed to be generic and not > specific to NFS, maybe it should stay that way?) In HEAD PBDRY is now a nop and the existing sigdeferstop() stuff should cover the calls in sys/rpc. > Also, since PBDRY on the sleeps sets TDF_SBDRY, I think the above patch > is ok for stable/9 without your recent head patch. Yep, exactly. > Thanks everyone for your help, rick Thanks for your debugging! -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 16:27:50 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B86CB288; Fri, 15 Feb 2013 16:27:50 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 451F27AA; Fri, 15 Feb 2013 16:27:49 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id r1FGWsWx091143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Feb 2013 17:32:55 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <511E61F5.1000805@omnilan.de> Date: Fri, 15 Feb 2013 17:27:33 +0100 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, freebsd-jail@freebsd.org Subject: new jail(8) ignoring devfs_ruleset? X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA0A96BBCFE6E7906134D658A" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Feb 2013 16:27:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA0A96BBCFE6E7906134D658A Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, like already posted, on 9.1-R, I highly appreciate the new jail(8) and jail.conf capabilities. Thanks for that extension! Accidentally I saw that "devfs_ruleset" seems to be ignored. If I list /dev/ I see all the hosts disk devices etc. I set "devfs_ruleset =3D 4;" and "enforce_statfs =3D 1;" in jail.conf. Inside the jail, sysctl security.jail.devfs_ruleset returnes "1". But like mentioned, I can access all devices... Thanks for any help, -Harry (not subscribed to freebsd-jail@) --------------enigA0A96BBCFE6E7906134D658A 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) iEYEARECAAYFAlEeYf0ACgkQLDqVQ9VXb8hE4wCgvsxHV/2So2JRMsbARy8wp6M5 FMQAoMVB6EtJo/1rHTZryPN4as3LPObG =7PSm -----END PGP SIGNATURE----- --------------enigA0A96BBCFE6E7906134D658A-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 16:43:18 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7E21B591 for ; Fri, 15 Feb 2013 16:43:18 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id EC716852 for ; Fri, 15 Feb 2013 16:43:17 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id r1FGmTG4093004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Feb 2013 17:48:29 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <511E65A4.1050304@omnilan.de> Date: Fri, 15 Feb 2013 17:43:16 +0100 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: mount lag, umounting returns wrong "Device busy" X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5871917530EFF50C06433BF3" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Feb 2013 16:43:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5871917530EFF50C06433BF3 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, while playing with new jail features, I recognized that manually umounting doesn't work as I'd expect. After jail has been destroyed, the following mountpoint is active: /dev/gpt/jailname1ROOT on /.jail.jailname1 (ufs, local, read-only) There was var mounted to /.jail.jailname1/var but that sucessfully umount= ed. 'fstat' also shows no open files in /.jail.jailname1 But when I do 'umount /.jail.jailname' I get "Device busy" returned. Some minutes later umounting works. But I always have to wait some time, although nothing is open and nothing is mounted above. Does anybody have an idea what could cause that false "Device busy"? -Harry --------------enig5871917530EFF50C06433BF3 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) iEYEARECAAYFAlEeZaQACgkQLDqVQ9VXb8gsHACdFEqlCR6P/TidOaRy5szVEzLI ZMgAnR19U1FX5jl7aBDZHXs6hXCKPGY3 =HXx2 -----END PGP SIGNATURE----- --------------enig5871917530EFF50C06433BF3-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 16:51:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B78A9817 for ; Fri, 15 Feb 2013 16:51:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id 4EF568AE for ; Fri, 15 Feb 2013 16:51:11 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hi8so1418753wib.1 for ; Fri, 15 Feb 2013 08:51:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=cdOKNOdNL1L+rVZTpr4IsNk0NpfMr7PLyK5kJS2Mdk0=; b=st6e7dchNp2iwTu7Q/UVFEMRR4LyODQ6lOe573z7SVNI9xNRb5UkEuV+L0lm1uYKUX tZ5dKKOzX6X2Un3SyIHKU3thQ0jvNU0lQWZz/W+g9YaW7nHl5qow60zKyvDcNKFU1jfV Ll4i892HZ7tXK6jxADnHdnwadpMLaKIlAy2vA/5Sp4osgDKhNoV/jLEEnYHlerjnLN9l qDXOg3HYSAzbh/fD8oPOZ0/XqD3cJnp8YemXq+ZxhsCgJHcTJJ5bNRNJhWW5KxFscEDB lw+qmoHSF+IMp1C2hfQc5XKJoEPtPv2Tl0XOwZiS9YLT2SxojraGGjvBIybAjoTXpnu1 7Llw== X-Received: by 10.180.76.84 with SMTP id i20mr5576246wiw.9.1360947067020; Fri, 15 Feb 2013 08:51:07 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id fg6sm6380360wib.10.2013.02.15.08.51.04 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 15 Feb 2013 08:51:05 -0800 (PST) Date: Fri, 15 Feb 2013 17:50:53 +0100 From: Mateusz Guzik To: Harald Schmalzbauer Subject: Re: mount lag, umounting returns wrong "Device busy" Message-ID: <20130215165052.GA11727@dft-labs.eu> References: <511E65A4.1050304@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <511E65A4.1050304@omnilan.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 16:51:12 -0000 On Fri, Feb 15, 2013 at 05:43:16PM +0100, Harald Schmalzbauer wrote: > Hello, > > while playing with new jail features, I recognized that manually > umounting doesn't work as I'd expect. > After jail has been destroyed, the following mountpoint is active: > /dev/gpt/jailname1ROOT on /.jail.jailname1 (ufs, local, read-only) > > There was var mounted to /.jail.jailname1/var but that sucessfully umounted. > 'fstat' also shows no open files in /.jail.jailname1 > > But when I do 'umount /.jail.jailname' I get "Device busy" returned. > Some minutes later umounting works. > But I always have to wait some time, although nothing is open and > nothing is mounted above. > > Does anybody have an idea what could cause that false "Device busy"? > My guess is that the jail was not dead yet and it held a reference for /.jail.jailname1's vnode. jls -v should show the jail. I don't know if this can happen, but my guess is that not-yet-expired network connections hold reference to a jail preventing it from being destroyed. So I would definitely checkout netstat output. There may be other posibilities, but nothing obvious comes to my mind at the moment. -- Mateusz Guzik From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 17:07:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D072CE95; Fri, 15 Feb 2013 17:07:32 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 5D599967; Fri, 15 Feb 2013 17:07:31 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id r1FHCh2s095918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Feb 2013 18:12:43 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <511E6B52.4020203@omnilan.de> Date: Fri, 15 Feb 2013 18:07:30 +0100 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: Mateusz Guzik , freebsd-jail@freebsd.org Subject: Re: mount lag, umounting returns wrong "Device busy" References: <511E65A4.1050304@omnilan.de> <20130215165052.GA11727@dft-labs.eu> In-Reply-To: <20130215165052.GA11727@dft-labs.eu> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig438B4AF40B8778F9AB84DB45" 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, 15 Feb 2013 17:07:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig438B4AF40B8778F9AB84DB45 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable schrieb Mateusz Guzik am 15.02.2013 17:50 (localtime): > On Fri, Feb 15, 2013 at 05:43:16PM +0100, Harald Schmalzbauer wrote: >> Hello, >> >> while playing with new jail features, I recognized that manually >> umounting doesn't work as I'd expect. >> After jail has been destroyed, the following mountpoint is active: >> /dev/gpt/jailname1ROOT on /.jail.jailname1 (ufs, local, read-only)= >> >> There was var mounted to /.jail.jailname1/var but that sucessfully umo= unted. >> 'fstat' also shows no open files in /.jail.jailname1 >> >> But when I do 'umount /.jail.jailname' I get "Device busy" returned. >> Some minutes later umounting works. >> But I always have to wait some time, although nothing is open and >> nothing is mounted above. >> >> Does anybody have an idea what could cause that false "Device busy"? >> > My guess is that the jail was not dead yet and it held a reference for > /.jail.jailname1's vnode. > > jls -v should show the jail. > > I don't know if this can happen, but my guess is that not-yet-expired > network connections hold reference to a jail preventing it from being > destroyed. So I would definitely checkout netstat output. There may be > other posibilities, but nothing obvious comes to my mind at the moment.= Good hint, I found out that returning the NIC (using jail with vnet) takes some time and as soon as the NIC shows up back in the host, I also can umount the jail's root mount point. I have no idea about the internals of moving NICs. Is it "normal" that it takes some time to return the NIC? Almost every time I remove the jail (jail -r), I have to issue the command twice. First, I see services getting stoped, but then the line: jail: kevent: No such process 'jail -r' cancels at that point (jls shows it active) After the second 'jail -r' I get the following lines: =2E Terminated gentlemail: removed umount: unmount of /.jail.jailname1 failed: Device busy Then 'jls' doesn't list the jail anymore, but the NIC still doesn't show up in the hosts network stack. And that's the cause for keeping the root mountpoint busy... Could that be related to the wrong umount-order with 'jail -r'? Thanks, -Harry --------------enig438B4AF40B8778F9AB84DB45 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) iEYEARECAAYFAlEea1IACgkQLDqVQ9VXb8hQeQCZAaGLpTShJ23DaP4r/O19eNqv FTsAoLqq0uyH6g1fL2GfuTRMzsBxzDA3 =caNc -----END PGP SIGNATURE----- --------------enig438B4AF40B8778F9AB84DB45-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 17:18:30 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D7DA1267 for ; Fri, 15 Feb 2013 17:18:30 +0000 (UTC) (envelope-from bartsch@dssgmbh.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 40AF59D6 for ; Fri, 15 Feb 2013 17:18:30 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 5DC445E63A; Fri, 15 Feb 2013 18:18:29 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id UwF7gW1_VICr; Fri, 15 Feb 2013 18:18:25 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 7D3D55E62A; Fri, 15 Feb 2013 18:18:25 +0100 (CET) Received: from pcadmin.incore (pcadmin.incore [192.168.0.140]) by mail.incore (Postfix) with ESMTPSA id 5A13B50857; Fri, 15 Feb 2013 18:18:25 +0100 (CET) Message-ID: <511E6DE0.4030303@dssgmbh.de> Date: Fri, 15 Feb 2013 18:18:24 +0100 From: Alfred Bartsch User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:7.0.1) Gecko/20111007 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: some issues with /usr/sbin/service References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> In-Reply-To: <20130215105710.GA6130@icarus.home.lan> X-Enigmail-Version: undefined 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: Fri, 15 Feb 2013 17:18:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jeremy, thanks for your quick response. If I understand you right, you don't see any necessity for updating /usr/sbin/service. I'll try to make my point of view more comprehensible. Am 15.02.2013 11:57, schrieb Jeremy Chadwick: > On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote: >> we want to use this script for server administration purposes. >> After doing some testing, for now there are following issues >> left: >> >> 1) every execution of "service -e" casts a bunch of unnecessary >> warnings into /var/log/messages: "... /usr/sbin/service: WARNING: >> $_enable is not set properly - see rc.conf(5)." This is >> caused by calling "checkyesno()", provided by /etc/subr. It could >> be solved by using a local function, named "checkyes" or >> similar. >> >> The following patch prohibits these annoying messages: {snip} > > Your patch, in effectively, "rewrites" checkyesno() to remove the > warn() call in cases where xxx_enable variables are set to values > other than yes/true/on/1 or no/false/off/0. > Yes, that's exactly my proposition. > Here's a better idea: > > Fix your /etc/rc.conf xxx_enable variables which contain values > that aren't permitted. That's what the warn() is for -- to tell > you to fix them. :-) That's not the point. To my knowledge all wrong settings of xxx_enable are reliably discovered during system startup, where all subr procedures are called with "start" as an argument from /etc/rc. At least in my environment(s) there are no such reported warnings from startup or shutdown. "service -e" does some heuristic attempts to redetermine the "original" startup setting of the XXX_enable variable without executing the startup script, and thus fails in all cases where this variable setting is done exclusively via the startup script itself. /usr/bin/service can be run at any time, even if the variable settings of the system startup (/etc/rc) are no longer valid. > > If there are ports (or worse, rc.d scripts) out there which > recommend xxx_enable variables with non-permitted values, then > these ports need to be fixed, not rc.subr(8) nor service(8). > Please disclose what those are so they can be fixed. > > However, "service -e" does not emit warnings on my 2 systems: The responsible "warn()" function emits messages to stderr and/or syslog, but stderr is redirected to /dev/null in /usr/sbin/service, so these messages can only be seen in /var/log/messages or /var/log/all.log, if syslog is configured as appropriate (user.notice) and /usr/bin/logger is executable. > > root@icarus:~ # service -e /etc/rc.d/hostid /etc/rc.d/zvol > /etc/rc.d/ddb /etc/rc.d/hostid_save /etc/rc.d/zfs > /etc/rc.d/cleanvar /etc/rc.d/ip6addrctl /etc/rc.d/devd > /etc/rc.d/netwait /etc/rc.d/newsyslog /etc/rc.d/syslogd > /etc/rc.d/named /etc/rc.d/ntpdate /etc/rc.d/dmesg > /etc/rc.d/virecover /etc/rc.d/motd /etc/rc.d/ntpd /etc/rc.d/powerd > /usr/local/etc/rc.d/samba /usr/local/etc/rc.d/postfix > /usr/local/etc/rc.d/mysql-server /usr/local/etc/rc.d/apache22 > /etc/rc.d/sshd /etc/rc.d/cron /etc/rc.d/mixer /etc/rc.d/inetd > /etc/rc.d/gptboot > > root@omake:~ # service -e /etc/rc.d/hostid /etc/rc.d/ddb > /etc/rc.d/hostid_save /etc/rc.d/cleanvar /etc/rc.d/ip6addrctl > /etc/rc.d/devd /etc/rc.d/pflog /etc/rc.d/pf /etc/rc.d/netwait > /etc/rc.d/newsyslog /etc/rc.d/syslogd /etc/rc.d/named > /etc/rc.d/ntpdate /etc/rc.d/dmesg /etc/rc.d/virecover > /etc/rc.d/motd /etc/rc.d/ntpd /usr/local/etc/rc.d/sa-spamd > /usr/local/etc/rc.d/postfix /usr/local/etc/rc.d/dovecot > /usr/local/etc/rc.d/apache22 /etc/rc.d/sshd /etc/rc.d/cron > /etc/rc.d/mixer /etc/rc.d/inetd /etc/rc.d/gptboot > > Regardless: the permitted values (see above) should be documented > in rc.conf(5) somewhere; I don't see any values other than "yes" > documented, but I'm probably overlooking it. > This may be true for all system startup scripts (/etc/rc.d) but is definitively not true for local startup scripts (/usr/local/etc/rc.d, ...). Let us suppose you added "XXX_enable" settings for your daemons from ports to /etc/rc.conf and did not install any other port containing startup script(s). In this particular case there is no warning emitted. After installing additional ports containing rc.d scripts without modifying /etc/rc.conf, you are able to restart your system again and again without such warnings being emitted, in these cases XXX_enable of these additional ports normally defaults to "NO". During execution of "service -e", XXX_enable defaults to "" and therefore /etc/subr emits a warning, which is IMHO at least misleading. The proposed patch solves this issue for me, YMMV. >> 2) "service -e" does not show ALL enabled services, but only >> those who are explicitly enabled in /etc/defaults/rc.conf or >> /etc/rc.conf. Is that expected behavior? > > It is the expected behaviour as I understand it per the man page. > You should also see rc(8). > > As I understand it, an "enabled service" is not a process that's > running, but something that has a yes/true/on/1 value for its > xxx_enabled variable in rc.conf/related file. That's just how it > works. I'm fully aware of this concept, AFAIK. > If you're used to, for example, Solaris "svcs" then yes things are > different here. Unfortunately my UNIX experience is mostly limited to *BSD (FreeBSD since 4.5 or so). :-; > >> To catch all enabled services where the _enabled variable >> is set within the service procedure itself, perhaps a call like >> "service status" could help. > > There is already "service status". See rc(8) (search for > "status") or try it yourself on a running service. Example: > > root@icarus:~ # service postfix status postfix is running as pid > 1378. > > Can you rephrase or give an example of what you want? > The main difference between rc and service is that rc calls all scripts via run_rc_script(), and sources them in a subshell with $1="start" or "stop". Therefore all settings of "XXX_enable" in the script itself are being respected, whereas "service -e" is limited to "eval grep ..." Ports with "XXX_enable="YES" (or similar) in their rc.d script would be considered as enabled (and started) by /etc/rc. "service -e" would not catch any of these. This different behavior is IMHO at least unexpected, if not buggy. If every rc.d script would provide a "status" (or similar) function without changing the service's state, service(8) would be able to gather a complete list of enabled services, like rc(8), and some additional info, whether these services are actually running or not. Please don't hesitate to ask, if my phrasing is not fully intelligible to you. My English knowledge is definitely far away from native speaker level.:-) - -- Regards Alfred Bartsch Data-Service GmbH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEebeAACgkQ5QGe2JdVf3hSqACcC6xQi6b3w0heGHQSkopqBynH I8MAoJJoV3dFTifa4F9PJXnY50LKKhYM =fAdN -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 19:32:13 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5776E50C for ; Fri, 15 Feb 2013 19:32:13 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 30057FD4 for ; Fri, 15 Feb 2013 19:32:13 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U6R10-000GDj-St; Fri, 15 Feb 2013 14:32:10 -0500 Date: Fri, 15 Feb 2013 14:32:10 -0500 From: Gary Palmer To: Jeremy Chadwick Subject: Re: some issues with /usr/sbin/service Message-ID: <20130215193210.GB85777@in-addr.com> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130215105710.GA6130@icarus.home.lan> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-stable@FreeBSD.org, Alfred Bartsch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Feb 2013 19:32:13 -0000 On Fri, Feb 15, 2013 at 02:57:10AM -0800, Jeremy Chadwick wrote: > On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote: > > we want to use this script for server administration purposes. After > > doing some testing, for now there are following issues left: > > > > 1) every execution of "service -e" casts a bunch of unnecessary > > warnings into /var/log/messages: > > "... /usr/sbin/service: WARNING: $_enable is not set > > properly - see rc.conf(5)." > > This is caused by calling "checkyesno()", provided by /etc/subr. It > > could be solved by using a local function, named "checkyes" or similar. > > > > The following patch prohibits these annoying messages: > > {snip} > > Your patch, in effectively, "rewrites" checkyesno() to remove the warn() > call in cases where xxx_enable variables are set to values other than > yes/true/on/1 or no/false/off/0. > > Here's a better idea: > > Fix your /etc/rc.conf xxx_enable variables which contain values that > aren't permitted. That's what the warn() is for -- to tell you to fix > them. :-) It also warns if xxx_enable isn't set. I have a number of ports installed which I don't want to run by default but may run later, or which have daemons but I don't want the daemon but some other functionality. rsync and fetchmail are two perfect examples of the latter. If I don't have xxx_enable in /usr/local/etc/rc.conf I get the warning. Should I really have to go through and explicitly set the xxx_enable flags to "no"? Or should the code be smart enough to recognise that the variable not being present is equivalent to "no"? If the requirement is that all installed rc.d scripts have a xxx_enable flag set to yes or no at all times, then the current ports infrastructure is sadly lacking as I don't have anything under /usr/local/etc/defaults/ at all (if that is even a valid location). And I'd prefer ports not try and automagically frob /etc/rc.conf, /etc/rc.conf.local or /etc/defaults/rc.conf to add/remove xxx_enable lines as that can go wrong. Gary From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 21:20:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BBA76DD2 for ; Fri, 15 Feb 2013 21:20:22 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id 9E808739 for ; Fri, 15 Feb 2013 21:20:22 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 0f8e1l0060lTkoCA1lLMMm; Fri, 15 Feb 2013 21:20:21 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta04.emeryville.ca.mail.comcast.net with comcast id 0lLL1l0061t3BNj8QlLL5e; Fri, 15 Feb 2013 21:20:21 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2BDE373A1C; Fri, 15 Feb 2013 13:20:20 -0800 (PST) Date: Fri, 15 Feb 2013 13:20:20 -0800 From: Jeremy Chadwick To: Gary Palmer Subject: Re: some issues with /usr/sbin/service Message-ID: <20130215212020.GA17516@icarus.home.lan> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130215193210.GB85777@in-addr.com> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360963221; bh=nsb9wjjS9N/YHRRLrv2l/VD6eVEAE7YBRmFXrGryxHc=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=jReGCt+GUZL4wXJOUFlSNywgJA849NiV5+rB2C848imLzR3/MWBNyGOd1N1wxh4Ua SRClx7H28+h8nLcJ6mDdwYouiPQ4S2HfLB+eWaM0GEfMaTGYcbTosqZNzRudelRlL2 jmsS9pktCIb+urF+ES90gLpfidGx6yWl6QO9fSdIF/lsyyJr+Zrrs+myXBNqRDZjDK QWnB32jqBVyHWBDF/DMFDXgOtKtbPrLLWpl5/KeMmFE+PY5tiN6KSrsqjfMvL4ApJn HrUPSmHyeF1Pa3YaX9Vn1IdEPWscAniccMWwAVuQ1QpA11tUaH8y05m/CAYmWRWYKn X+66aMCg6xFTg== Cc: freebsd-stable@FreeBSD.org, Alfred Bartsch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Feb 2013 21:20:22 -0000 On Fri, Feb 15, 2013 at 02:32:10PM -0500, Gary Palmer wrote: > On Fri, Feb 15, 2013 at 02:57:10AM -0800, Jeremy Chadwick wrote: > > On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote: > > > we want to use this script for server administration purposes. After > > > doing some testing, for now there are following issues left: > > > > > > 1) every execution of "service -e" casts a bunch of unnecessary > > > warnings into /var/log/messages: > > > "... /usr/sbin/service: WARNING: $_enable is not set > > > properly - see rc.conf(5)." > > > This is caused by calling "checkyesno()", provided by /etc/subr. It > > > could be solved by using a local function, named "checkyes" or similar. > > > > > > The following patch prohibits these annoying messages: > > > {snip} > > > > Your patch, in effectively, "rewrites" checkyesno() to remove the warn() > > call in cases where xxx_enable variables are set to values other than > > yes/true/on/1 or no/false/off/0. > > > > Here's a better idea: > > > > Fix your /etc/rc.conf xxx_enable variables which contain values that > > aren't permitted. That's what the warn() is for -- to tell you to fix > > them. :-) > > It also warns if xxx_enable isn't set. I have a number of ports installed > which I don't want to run by default but may run later, or which have > daemons but I don't want the daemon but some other functionality. > rsync and fetchmail are two perfect examples of the latter. > > If I don't have xxx_enable in /usr/local/etc/rc.conf I get the warning. > Should I really have to go through and explicitly set the xxx_enable flags > to "no"? Or should the code be smart enough to recognise that the variable > not being present is equivalent to "no"? > > If the requirement is that all installed rc.d scripts have a xxx_enable flag > set to yes or no at all times, then the current ports infrastructure is sadly > lacking as I don't have anything under /usr/local/etc/defaults/ at all (if > that is even a valid location). And I'd prefer ports not try and automagically > frob /etc/rc.conf, /etc/rc.conf.local or /etc/defaults/rc.conf to add/remove > xxx_enable lines as that can go wrong. This is the first I've heard of something called /usr/local/etc/rc.conf. What is this file? I don't see it mentioned as being read/used by rc_conf_files (see /etc/defaults/rc.conf), at least not via stock. Are you redefining rc_conf_files or are you somehow source'ing the file yourself? Regardless, I can't confirm that behaviour: root@icarus:~ # grep mysql_ /etc/rc.conf # mysql_enable="yes" # mysql_dbdir="/storage/mysql" root@icarus:~ # service -e /etc/rc.d/hostid /etc/rc.d/zvol /etc/rc.d/ddb /etc/rc.d/hostid_save /etc/rc.d/zfs /etc/rc.d/cleanvar /etc/rc.d/ip6addrctl /etc/rc.d/devd /etc/rc.d/netwait /etc/rc.d/newsyslog /etc/rc.d/syslogd /etc/rc.d/named /etc/rc.d/ntpdate /etc/rc.d/dmesg /etc/rc.d/virecover /etc/rc.d/motd /etc/rc.d/ntpd /etc/rc.d/powerd /usr/local/etc/rc.d/samba /usr/local/etc/rc.d/postfix /usr/local/etc/rc.d/apache22 /etc/rc.d/sshd /etc/rc.d/cron /etc/rc.d/mixer /etc/rc.d/inetd /etc/rc.d/gptboot Same goes for if I removed the commented-out lines (shouldn't matter but I tested it anyway). System: FreeBSD icarus.home.lan 9.1-STABLE FreeBSD 9.1-STABLE #0 r246644: Sun Feb 10 16:55:49 PST 2013 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64 amd64 root@icarus:~ # grep '$FreeBSD' /etc/rc /etc/rc.subr /etc/rc:# $FreeBSD: stable/9/etc/rc 233943 2012-04-06 11:07:44Z ed $ /etc/rc.subr:# $FreeBSD: stable/9/etc/rc.subr 243754 2012-12-01 15:46:27Z crees $ I fully agree that if this were the case (having to set xxx_enable="no" explicitly) that would be a bug. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 21:32:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8FE52815 for ; Fri, 15 Feb 2013 21:32:58 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by mx1.freebsd.org (Postfix) with ESMTP id 74A1D7CD for ; Fri, 15 Feb 2013 21:32:58 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta15.emeryville.ca.mail.comcast.net with comcast id 0ksd1l00317UAYkAFlYyFs; Fri, 15 Feb 2013 21:32:58 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta13.emeryville.ca.mail.comcast.net with comcast id 0lYx1l00D1t3BNj8ZlYxfU; Fri, 15 Feb 2013 21:32:57 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 27A0273A1C; Fri, 15 Feb 2013 13:32:57 -0800 (PST) Date: Fri, 15 Feb 2013 13:32:57 -0800 From: Jeremy Chadwick To: Gary Palmer Subject: Re: some issues with /usr/sbin/service Message-ID: <20130215213257.GA20155@icarus.home.lan> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com> <20130215212020.GA17516@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130215212020.GA17516@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360963978; bh=ByxRxs2JR1rHigIJbnsmLS4I1M7IfmmYL5yjCf7UQv0=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=el+6fqNh4poj6vsn6j1IxDFMyUHCm/91lcRZPaZ0mVlPFWn087U+eIWn4JiFeTdtc kzKHPGUTnc5e+JIEbqU7z/pePXjfJi8IUKpkC8urTqE4PhsMIevgww4i0SEOXVcS/4 PDGZpJY1umqIJqlCbzNJp9XHEyXLe9QOLmxBBYV/378fuWwK109SI1qua8Na7z5bUV suOeX8A5Tmdxym/CggSfO+p+gHCka/31ZLRuvA4HKOSRTJy+fg5Tc98BfSuCY2noOU f4ohiDEFiW9KAGUug1dyrQAccoPXogpkJ/9KmItx5j2KwlY9AxRvfNZFcByQ0MZpaA RHIAJ4M7aVfGw== Cc: freebsd-stable@FreeBSD.org, Alfred Bartsch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Feb 2013 21:32:58 -0000 On Fri, Feb 15, 2013 at 01:20:20PM -0800, Jeremy Chadwick wrote: > On Fri, Feb 15, 2013 at 02:32:10PM -0500, Gary Palmer wrote: > > On Fri, Feb 15, 2013 at 02:57:10AM -0800, Jeremy Chadwick wrote: > > > On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote: > > > > we want to use this script for server administration purposes. After > > > > doing some testing, for now there are following issues left: > > > > > > > > 1) every execution of "service -e" casts a bunch of unnecessary > > > > warnings into /var/log/messages: > > > > "... /usr/sbin/service: WARNING: $_enable is not set > > > > properly - see rc.conf(5)." > > > > This is caused by calling "checkyesno()", provided by /etc/subr. It > > > > could be solved by using a local function, named "checkyes" or similar. > > > > > > > > The following patch prohibits these annoying messages: > > > > {snip} > > > > > > Your patch, in effectively, "rewrites" checkyesno() to remove the warn() > > > call in cases where xxx_enable variables are set to values other than > > > yes/true/on/1 or no/false/off/0. > > > > > > Here's a better idea: > > > > > > Fix your /etc/rc.conf xxx_enable variables which contain values that > > > aren't permitted. That's what the warn() is for -- to tell you to fix > > > them. :-) > > > > It also warns if xxx_enable isn't set. I have a number of ports installed > > which I don't want to run by default but may run later, or which have > > daemons but I don't want the daemon but some other functionality. > > rsync and fetchmail are two perfect examples of the latter. > > > > If I don't have xxx_enable in /usr/local/etc/rc.conf I get the warning. > > Should I really have to go through and explicitly set the xxx_enable flags > > to "no"? Or should the code be smart enough to recognise that the variable > > not being present is equivalent to "no"? > > > > If the requirement is that all installed rc.d scripts have a xxx_enable flag > > set to yes or no at all times, then the current ports infrastructure is sadly > > lacking as I don't have anything under /usr/local/etc/defaults/ at all (if > > that is even a valid location). And I'd prefer ports not try and automagically > > frob /etc/rc.conf, /etc/rc.conf.local or /etc/defaults/rc.conf to add/remove > > xxx_enable lines as that can go wrong. > > This is the first I've heard of something called /usr/local/etc/rc.conf. > What is this file? I don't see it mentioned as being read/used by > rc_conf_files (see /etc/defaults/rc.conf), at least not via stock. Are > you redefining rc_conf_files or are you somehow source'ing the file > yourself? > > Regardless, I can't confirm that behaviour: > > root@icarus:~ # grep mysql_ /etc/rc.conf > # mysql_enable="yes" > # mysql_dbdir="/storage/mysql" > > root@icarus:~ # service -e > /etc/rc.d/hostid > /etc/rc.d/zvol > /etc/rc.d/ddb > /etc/rc.d/hostid_save > /etc/rc.d/zfs > /etc/rc.d/cleanvar > /etc/rc.d/ip6addrctl > /etc/rc.d/devd > /etc/rc.d/netwait > /etc/rc.d/newsyslog > /etc/rc.d/syslogd > /etc/rc.d/named > /etc/rc.d/ntpdate > /etc/rc.d/dmesg > /etc/rc.d/virecover > /etc/rc.d/motd > /etc/rc.d/ntpd > /etc/rc.d/powerd > /usr/local/etc/rc.d/samba > /usr/local/etc/rc.d/postfix > /usr/local/etc/rc.d/apache22 > /etc/rc.d/sshd > /etc/rc.d/cron > /etc/rc.d/mixer > /etc/rc.d/inetd > /etc/rc.d/gptboot > > Same goes for if I removed the commented-out lines (shouldn't matter but > I tested it anyway). > > System: > > FreeBSD icarus.home.lan 9.1-STABLE FreeBSD 9.1-STABLE #0 r246644: Sun Feb 10 16:55:49 PST 2013 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64 amd64 > > root@icarus:~ # grep '$FreeBSD' /etc/rc /etc/rc.subr > /etc/rc:# $FreeBSD: stable/9/etc/rc 233943 2012-04-06 11:07:44Z ed $ > /etc/rc.subr:# $FreeBSD: stable/9/etc/rc.subr 243754 2012-12-01 15:46:27Z crees $ > > I fully agree that if this were the case (having to set xxx_enable="no" > explicitly) that would be a bug. Follow up -- I read Alfred's most recent mail. Lo and behold, I find this in /var/log/messages (but such did not come to my terminal): Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). Cute. Agreed -- this is unacceptable on two levels (as I see it): 1) These messages should be going to stdout or stderr in some way, so honestly logger(8) should be called with the "-s" flag (IMO). 2) These messages should not be displayed at all (i.e. lack of an xxx_enable variable should imply xxx_enable="no"). I'll file a PR for this. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 21:58:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A8981EA8 for ; Fri, 15 Feb 2013 21:58:49 +0000 (UTC) (envelope-from karl@denninger.net) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 6A61D8AF for ; Fri, 15 Feb 2013 21:58:49 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.6/8.13.1) with ESMTP id r1FLwg8d018792 for ; Fri, 15 Feb 2013 15:58:42 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Fri Feb 15 15:58:42 2013 Message-ID: <511EAF8D.8090703@denninger.net> Date: Fri, 15 Feb 2013 15:58:37 -0600 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: And for our next trick (Audio problems, Envy24HT driver) X-Enigmail-Version: 1.5 X-Antivirus: avast! (VPS 130215-0, 02/15/2013), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 21:58:49 -0000 FreeBSD 9.1-STABLE #2 r244942M: Tue Feb 5 21:54:29 CST 2013 karl@dbms.denninger.net:/usr/obj/usr/src/sys/KSD-SMP (custom kernel is there to support PPS for my GPS clock) Attempting to add a generic card that claims to have a Envy24DT chipset in it; it identifies and loads under the snd_envy24ht driver as: pci6: at device 0.0 (no driver attached) pcm0: port 0xcc00-0xcc1f,0xc880-0xc8ff irq 16 at device 0.0 on pci6 pcm0: [GIANT-LOCKED] pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x2403 XIN2 Clock Source: 24.576MHz(96kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 and SPDIF receiver connected DAC #: 4 Multi-track converter type: AC'97(SDATA_OUT:packed) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0xff/0xff/0xff cat /dev/sndstat returns: [root@NewFS /boot/kernel]# cat /dev/sndstat FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64) Installed devices: pcm0: at io 0xcc00:32,0xc880:128 irq 16 (1p:1v/5r:1v) default So it appears it did attach properly. But.... an attempt to output something to /dev/dsp0 looks like it is, but nothing happens (no sound) ie: # sysctl -w hw.snd.verbose=2 # mpg123 some-mp3-file & # sndstat | more FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64) Installed devices: pcm0: at io 0xcc00:32,0xc880:128 irq 16 (1p:1v/5r:1v) default snddev flags=0x2a6 [pcm0:play:dsp0.p0]: spd 48000, fmt 0x00200010, flags 0x00002108, 0x00000004 interrupts 1343, underruns 0, feed 1343, ready 0 [b:16384/2048/8|bs:16384/2048/8] channel flags=0x2108 {userland} -> feeder_mixer(0x00200010) -> {hardware} pcm0:play:dsp0.p0[pcm0:virtual:dsp0.vp0]: spd 44100/48000, fmt 0x00200010, flags 0x1000012c, 0x00000029, pid 18573 (mpg123) interrupts 0, underruns 0, feed 1497, ready 65536 [b:0/0/0|bs:65536/2048/32] channel flags=0x1000012c {userland} -> feeder_root(0x00200010) -> feeder_volume(0x00200010) -> feeder_rate(0x00200010 q:1 44100 -> 48000) -> {hardware} ...... Says its running, and mpg123 has attached to it -- but no output. Mixer says the volume is on: [root@NewFS /boot/kernel]# mixer Mixer vol is currently set to 75:75 Mixer treble is currently set to 0:0 Mixer synth is currently set to 0:0 Mixer pcm is currently set to 75:75 Mixer speaker is currently set to 0:0 Mixer line is currently set to 75:75 Mixer mic is currently set to 0:0 Mixer cd is currently set to 0:0 Mixer mix is currently set to 0:0 Recording source: mic Ideas for further troubleshooting? -- -- Karl Denninger /The Market Ticker ®/ Cuda Systems LLC From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 22:17:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1277439D for ; Fri, 15 Feb 2013 22:17:11 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by mx1.freebsd.org (Postfix) with ESMTP id D5ED6949 for ; Fri, 15 Feb 2013 22:17:10 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta02.emeryville.ca.mail.comcast.net with comcast id 0jz91l0061HpZEsA2mHA12; Fri, 15 Feb 2013 22:17:10 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta14.emeryville.ca.mail.comcast.net with comcast id 0mH91l00T1t3BNj8amHA9e; Fri, 15 Feb 2013 22:17:10 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id DD87273A1C; Fri, 15 Feb 2013 14:17:09 -0800 (PST) Date: Fri, 15 Feb 2013 14:17:09 -0800 From: Jeremy Chadwick To: Gary Palmer Subject: Re: some issues with /usr/sbin/service Message-ID: <20130215221709.GA22268@icarus.home.lan> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com> <20130215212020.GA17516@icarus.home.lan> <20130215213257.GA20155@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130215213257.GA20155@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360966630; bh=EVBht6FJWaPvaZuhhwGxkAWEBGvHaeFxUVWBitz4Im0=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=mX/3buKkhsMZJwDqCadTvRfz6zYC00QXiTHPeVxLGStBl1EJafeb7iOCidYHxoa5E 3XFaWlAWBOfC0F6o2h7MYRf/e2V7WwMvQ43M1xKsDOYCsFpojOec4QWOYBod4VIOCF 1BUROVzvHjtGLM6LOzVNn3k5aMoOUmHXUs2DL6iGDpNzKEX14GzTGuiwCSi6qMzWSx 5hQDHn+HN3IkaHNuM+NrAWPTggBrhjiqzb0Ty/DWEhZbzhkyTmEAnTOReXpSj/VT+j NcsOSzOVXa/ul060VhZJA0u9YR/2uOuMiDy/KspPt+YTDnNLlRlhEf2/AX3MleSdTe OUcdTeStrC5fw== Cc: freebsd-stable@FreeBSD.org, Alfred Bartsch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Feb 2013 22:17:11 -0000 On Fri, Feb 15, 2013 at 01:32:57PM -0800, Jeremy Chadwick wrote: > I'll file a PR for this. http://www.freebsd.org/cgi/query-pr.cgi?pr=176181 -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 23:40:22 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 20E1A211; Fri, 15 Feb 2013 23:40:22 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [199.192.164.235]) by mx1.freebsd.org (Postfix) with ESMTP id EB610DEC; Fri, 15 Feb 2013 23:40:21 +0000 (UTC) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by m2.gritton.org (8.14.5/8.14.5) with ESMTP id r1FNeEpo043095; Fri, 15 Feb 2013 16:40:15 -0700 (MST) (envelope-from jamie@FreeBSD.org) Message-ID: <511EC759.4060704@FreeBSD.org> Date: Fri, 15 Feb 2013 16:40:09 -0700 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120126 Thunderbird/9.0 MIME-Version: 1.0 To: Harald Schmalzbauer Subject: Re: new jail(8) ignoring devfs_ruleset? References: <511E61F5.1000805@omnilan.de> In-Reply-To: <511E61F5.1000805@omnilan.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-jail@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, 15 Feb 2013 23:40:22 -0000 On 02/15/13 09:27, Harald Schmalzbauer wrote: > Hello, > > like already posted, on 9.1-R, I highly appreciate the new jail(8) and > jail.conf capabilities. Thanks for that extension! > > Accidentally I saw that "devfs_ruleset" seems to be ignored. > If I list /dev/ I see all the hosts disk devices etc. > I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf. > Inside the jail, > sysctl security.jail.devfs_ruleset returnes "1". > But like mentioned, I can access all devices... > > Thanks for any help, > > -Harry devfs_ruleset is only used along with mount.devfs - do you also have that set in jail.conf? - Jamie From owner-freebsd-stable@FreeBSD.ORG Sat Feb 16 00:17:33 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F2667EFB; Sat, 16 Feb 2013 00:17:32 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id AED70F5D; Sat, 16 Feb 2013 00:17:32 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U6VT9-000GbI-Gr; Fri, 15 Feb 2013 19:17:31 -0500 Date: Fri, 15 Feb 2013 19:17:31 -0500 From: Gary Palmer To: Jeremy Chadwick Subject: Re: some issues with /usr/sbin/service Message-ID: <20130216001731.GD85777@in-addr.com> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com> <20130215212020.GA17516@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130215212020.GA17516@icarus.home.lan> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-stable@FreeBSD.org, Alfred Bartsch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Feb 2013 00:17:33 -0000 On Fri, Feb 15, 2013 at 01:20:20PM -0800, Jeremy Chadwick wrote: > On Fri, Feb 15, 2013 at 02:32:10PM -0500, Gary Palmer wrote: > > On Fri, Feb 15, 2013 at 02:57:10AM -0800, Jeremy Chadwick wrote: > > > On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote: > > > > we want to use this script for server administration purposes. After > > > > doing some testing, for now there are following issues left: > > > > > > > > 1) every execution of "service -e" casts a bunch of unnecessary > > > > warnings into /var/log/messages: > > > > "... /usr/sbin/service: WARNING: $_enable is not set > > > > properly - see rc.conf(5)." > > > > This is caused by calling "checkyesno()", provided by /etc/subr. It > > > > could be solved by using a local function, named "checkyes" or similar. > > > > > > > > The following patch prohibits these annoying messages: > > > > {snip} > > > > > > Your patch, in effectively, "rewrites" checkyesno() to remove the warn() > > > call in cases where xxx_enable variables are set to values other than > > > yes/true/on/1 or no/false/off/0. > > > > > > Here's a better idea: > > > > > > Fix your /etc/rc.conf xxx_enable variables which contain values that > > > aren't permitted. That's what the warn() is for -- to tell you to fix > > > them. :-) > > > > It also warns if xxx_enable isn't set. I have a number of ports installed > > which I don't want to run by default but may run later, or which have > > daemons but I don't want the daemon but some other functionality. > > rsync and fetchmail are two perfect examples of the latter. > > > > If I don't have xxx_enable in /usr/local/etc/rc.conf I get the warning. > > Should I really have to go through and explicitly set the xxx_enable flags > > to "no"? Or should the code be smart enough to recognise that the variable > > not being present is equivalent to "no"? > > > > If the requirement is that all installed rc.d scripts have a xxx_enable flag > > set to yes or no at all times, then the current ports infrastructure is sadly > > lacking as I don't have anything under /usr/local/etc/defaults/ at all (if > > that is even a valid location). And I'd prefer ports not try and automagically > > frob /etc/rc.conf, /etc/rc.conf.local or /etc/defaults/rc.conf to add/remove > > xxx_enable lines as that can go wrong. > > This is the first I've heard of something called /usr/local/etc/rc.conf. Sorry, my brain was ahead of where my fingers were and got the path wrong. I of course meant /etc/rc.conf. > Regardless, I can't confirm that behaviour: As you found, it gets logged rather than output to stdout or stderr. Feb 15 19:21:18 desktop gpalmer: /usr/sbin/service: WARNING: $xfs_enable is not set properly - see rc.conf(5). Feb 15 19:21:18 desktop gpalmer: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). Feb 15 19:21:18 desktop gpalmer: /usr/sbin/service: WARNING: $rrdcached_enable is not set properly - see rc.conf(5). (etc) I've come across something else outputing that error, but it probably all comes from the same place. Either the rc processor needs to treat the flag not being set as equal to "no", or the ports infrastructure needs to start installing something to make foo_enable="no" appear in the defaults system somewhere Gary From owner-freebsd-stable@FreeBSD.ORG Sat Feb 16 04:31:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C03A2C3A; Sat, 16 Feb 2013 04:31:28 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 6EB3195A; Sat, 16 Feb 2013 04:31:28 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.189]) by hub.org (Postfix) with ESMTP id D2188114577C; Sat, 16 Feb 2013 00:31:19 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.189]) (amavisd-maia, port 10024) with ESMTP id 47921-08; Sat, 16 Feb 2013 04:31:16 +0000 (UTC) Received: from [192.168.0.52] (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id 5CEF4114577B; Sat, 16 Feb 2013 00:31:14 -0400 (AST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 9-STABLE -> NFS -> NetAPP: From: Marc Fournier In-Reply-To: <201302150844.43188.jhb@freebsd.org> Date: Fri, 15 Feb 2013 20:31:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1964289267.3041689.1360897556427.JavaMail.root@erie.cs.uoguelph.ca> <201302150844.43188.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1499) Cc: Konstantin Belousov , Rick Macklem , 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, 16 Feb 2013 04:31:28 -0000 Trying the patch now =85 but what do you mean by using 'SIGSTOP'? I = generally do a 'kill -HUP' then when that doesn't work 'kill -9' =85 = should Iuse -STOP instead of 9? On 2013-02-15, at 5:44 AM, John Baldwin wrote: >=20 > I think this is the right idea, but in HEAD with the sigdeferstop() = changes it=20 > should just check for TDF_SBDRY instead of adding a new parameter. I = think > checking for TDF_SBDRY will work even in 9 (and will make the patch = smaller). =20 > Also, I think this is only needed for stop signals. Other suspend = requests=20 > will eventually resume the thread, it is only stop signals that can = cause the=20 > thread to get stuck indefinitely (since it depends on the user sending=20= > SIGCONT). >=20 > Marc, are you using SIGSTOP? >=20 > Index: kern_thread.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- kern_thread.c (revision 246122) > +++ kern_thread.c (working copy) > @@ -795,6 +795,17 @@ thread_suspend_check(int return_instead) > return (ERESTART); >=20 > /* > + * Ignore suspend requests for stop signals if they > + * are deferred. > + */ > + if (P_SHOULDSTOP(p) =3D=3D P_STOPPED_SIG && > + td->td_flags & TDF_SBDRY) { > + KASSERT(return_instead, > + ("TDF_SBDRY set for unsafe = thread_suspend_check")); > + return (0); > + } > + > + /* > * If the process is waiting for us to exit, > * this thread should just suicide. > * Assumes that P_SINGLE_EXIT implies P_STOPPED_SINGLE. >=20 > --=20 > John Baldwin From owner-freebsd-stable@FreeBSD.ORG Sat Feb 16 08:23: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]) by hub.freebsd.org (Postfix) with ESMTP id 47F22815 for ; Sat, 16 Feb 2013 08:23:38 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward5h.mail.yandex.net (forward5h.mail.yandex.net [IPv6:2a02:6b8:0:f05::5]) by mx1.freebsd.org (Postfix) with ESMTP id D43E7F51 for ; Sat, 16 Feb 2013 08:23:37 +0000 (UTC) Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward5h.mail.yandex.net (Yandex) with ESMTP id EAA89D01B78; Sat, 16 Feb 2013 12:23:34 +0400 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id A66A3170040E; Sat, 16 Feb 2013 12:23:34 +0400 (MSK) Received: from 93.91.2.200.tel.ru (93.91.2.200.tel.ru [93.91.2.200]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id NYQKI8hn-NYQ8PRBL; Sat, 16 Feb 2013 12:23:34 +0400 Message-ID: <511F4205.50509@passap.ru> Date: Sat, 16 Feb 2013 12:23:33 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: some issues with /usr/sbin/service References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com> <20130215212020.GA17516@icarus.home.lan> <20130215213257.GA20155@icarus.home.lan> In-Reply-To: <20130215213257.GA20155@icarus.home.lan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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, 16 Feb 2013 08:23:38 -0000 16.02.2013 01:32, Jeremy Chadwick пишет: > Follow up -- I read Alfred's most recent mail. Lo and behold, I find > this in /var/log/messages (but such did not come to my terminal): > > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not set properly - see rc.conf(5). > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). > > Cute. Agreed -- this is unacceptable on two levels (as I see it): > > 1) These messages should be going to stdout or stderr in some way, so > honestly logger(8) should be called with the "-s" flag (IMO). Fully agreed here. > 2) These messages should not be displayed at all (i.e. lack of an > xxx_enable variable should imply xxx_enable="no"). I see this message as one more level of supervision. If undefined at /etc/make.conf the value of xxx_enable is "no" from the system's POV (i.e. the service is not strarted). From the admininstrators's POV the port was installed BUT is not used. It's up to admininstrator whether it's OK or not -- just let him remind. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-stable@FreeBSD.ORG Sat Feb 16 08:33:20 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4892A970 for ; Sat, 16 Feb 2013 08:33:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id B194EF8D for ; Sat, 16 Feb 2013 08:33:19 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hm14so1946507wib.9 for ; Sat, 16 Feb 2013 00:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9yjNq79NfTHIf3AGQGpOoVMlgsh6YT6lI6kJ8WJl4BQ=; b=F9oWooD42/D8rl1RQrNJv/6C7O2KDhlnSNTSAWPh3z3puw9wm6/lriLpaF+zQd4pee 1EaIiCkiJW9iJXVQ2iYFBFYls2yujGfbbyYQsqCfFHrghwKRE8sdxMBLCcsfJjMQiHEu aPWYsycFHGku3flzgWS5gQULabtJ78qrcL4Sq3YWCXC5sHOq1x6PKBCtbXErX7TMUT2H WqV1D+byX8LO/1aGRs24hgqcDf4h0gcRErQdVfvTEsv3tHu/lJSUsJ4qoxGShMa9WHQ0 pXfDfyIfN0tiM9jEfVL/IQ0QjhkKgzwmOIkBvmgc6Ij90wf+NzEaL2+Ondzh7xP9jicx PLIw== MIME-Version: 1.0 X-Received: by 10.180.84.165 with SMTP id a5mr10466315wiz.6.1361003598424; Sat, 16 Feb 2013 00:33:18 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Sat, 16 Feb 2013 00:33:18 -0800 (PST) In-Reply-To: <511CECCC.60400@grosbein.pp.ru> References: <511CECCC.60400@grosbein.pp.ru> Date: Sat, 16 Feb 2013 00:33:18 -0800 X-Google-Sender-Auth: xV6DGke51ShVWf0OMu6ofwXxUtY Message-ID: Subject: Re: i386: vm.pmap kernel local race condition From: Adrian Chadd To: Eugene Grosbein 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: Sat, 16 Feb 2013 08:33:20 -0000 .. as a side note, you should use the concurrency extension for helpers; it won't need 500 helpers.. Adrian On 14 February 2013 05:55, Eugene Grosbein wrote: > Hi! > > I've got FreeBSD 8.3-STABLE/i386 server that can be reliably panicked > using just 'squid -k rotatelog' command. It seems the system suffers > from the problem described here: > > http://cxsecurity.com/issue/WLB-2010090156 > > I could not find any FreeBSD Security Advisory containing a fix. > > My server has 4G physical RAM (about 3.2G available) and runs > squid (about 110M VSS) with 500 ntlm_auth subprocesses. > Lesser number of ntlm_auth sometimes results in squid crash > as it sometimes has several hundreds requests per second to authorize > and is intolerant to exhaustion of free ntlm_auth. > > "squid -k rotatelog" at midnight results in crash: > > Feb 14 00:03:00 irl savecore: reboot after panic: get_pv_entry: increase vm.pmap.shpgperproc > Feb 14 00:03:00 irl savecore: writing core to vmcore.1 > > Btw, I have coredump. > > vm.pmap.shpgperproc has default value (200) here, as well as m.v_free_min, > vm.v_free_reserved, and vm.v_free_target and KVA_PAGES. > > These crashes are pretty regular > > # last|fgrep reboot > reboot ~ Thu Feb 14 00:03 > reboot ~ Wed Feb 13 19:08 > reboot ~ Wed Feb 13 10:40 > reboot ~ Wed Feb 13 00:04 > reboot ~ Tue Feb 12 00:09 > reboot ~ Mon Feb 11 00:03 > reboot ~ Sun Feb 10 00:03 > reboot ~ Thu Feb 7 00:03 > reboot ~ Wed Feb 6 10:52 > reboot ~ Sun Feb 3 00:03 > reboot ~ Sat Feb 2 00:03 > > May this be considered as security problem? > Can it be fixed without switch to amd64? > I have only remote access to this production server, no serial console. > > Eugene Grosbein > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sat Feb 16 09:21:35 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B1B8B24C for ; Sat, 16 Feb 2013 09:21:35 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:48]) by mx1.freebsd.org (Postfix) with ESMTP id 941E1173 for ; Sat, 16 Feb 2013 09:21:35 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta05.emeryville.ca.mail.comcast.net with comcast id 0xMa1l0011HpZEsA5xMaNH; Sat, 16 Feb 2013 09:21:34 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta14.emeryville.ca.mail.comcast.net with comcast id 0xMZ1l0081t3BNj8axMZHs; Sat, 16 Feb 2013 09:21:34 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A2FFD73A1C; Sat, 16 Feb 2013 01:21:33 -0800 (PST) Date: Sat, 16 Feb 2013 01:21:33 -0800 From: Jeremy Chadwick To: Boris Samorodov Subject: Re: some issues with /usr/sbin/service Message-ID: <20130216092133.GA31449@icarus.home.lan> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com> <20130215212020.GA17516@icarus.home.lan> <20130215213257.GA20155@icarus.home.lan> <511F4205.50509@passap.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <511F4205.50509@passap.ru> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361006494; bh=UwkynGc+x64NoQfxBEeY1B3Dp4cU77PsK9Q81SdixhQ=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=XCYQnYW8JrlF0WlRutHc2yfZyLW2xkx79VTyZnYbbGS/D3ckwUWb8ftMcHNWIDoZP JIGEWFB5El5+iIx23FhLFwF29zHaA54vmL3jiirmnqmJfXdUP1h7tmcjUWEp2whvpl 4R3vo5rtPSm+gkYMWohuGiiFauF7CsmtaBfsBHxtAphfE6Dzn2IQIf+hrVAgDnlShX 6H8P8EtF1cJK3G71Z6ZUnFJmsX1tlaHTmRZsl528jBGNWjbCTeUhpZ+fqFwhtksGtB V4p8+fFzNQnGHZpmcR8SxUJPWLKeU+YjVoS4Mqw2swCkVP0FmxS3NfZ0HFkgSSf80Y UPzI4M8856n3g== 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, 16 Feb 2013 09:21:35 -0000 On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: > 16.02.2013 01:32, Jeremy Chadwick ??????????: > > > Follow up -- I read Alfred's most recent mail. Lo and behold, I find > > this in /var/log/messages (but such did not come to my terminal): > > > > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). > > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not set properly - see rc.conf(5). > > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). > > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). > > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). > > > > Cute. Agreed -- this is unacceptable on two levels (as I see it): > > > > 1) These messages should be going to stdout or stderr in some way, so > > honestly logger(8) should be called with the "-s" flag (IMO). > > Fully agreed here. It turns out logger -s has no effect, just like how the echo 1>&2 statements in warn() and err() have no effect either (these should be outputting the warnings in question to stderr) -- see rc.subr's source for what I'm referring to. Gary and I have been discussing this off-list and the reason has been found: service(8) has this code in it: checkyesno $rcvar 2>/dev/null && echo $file This explains why there's no warn() or err() output on the terminal -- it's being redirected to /dev/null prior. I do not know who maintains the rc(8) and rc.subr(8) framework, but they've got their work cut out for them. (Note: the echo statements in warn() and err() could be replaced with "logger -s" as I said; this would allow the "echo 1>&2" to be removed) > > 2) These messages should not be displayed at all (i.e. lack of an > > xxx_enable variable should imply xxx_enable="no"). > > I see this message as one more level of supervision. > > If undefined at /etc/make.conf the value of xxx_enable is "no" from the > system's POV (i.e. the service is not strarted). From the > admininstrators's POV the port was installed BUT is not used. It's up > to admininstrator whether it's OK or not -- just let him remind. I believe the point you're trying to make is that the warning in question should 'act as a reminder to the administrator that they need to set xxx_enable="yes" in rc.conf'. If not: please explain if you could what you mean, because I don't understand. If so: I strongly disagree with this method of approach, as what you've proposed is a borderline straw man argument. Reminding the admin to set xxx_enable is presently done inside most ports' pkg-message. IMO, this should really be done inside bsd.port.mk when USE_RC_SUBR is used, emitting a message during install that says something like: To enable the xxx service, please add the following to /etc/rc.conf: xxx_enable="yes" Of course, I don't know if this would work for packages. The current message for is this: WARNING: $xxx_enable is not set properly - see rc.conf(5). The message is entirely misleading for this specific situation; it isn't "reminding" an administrator -- if anything it's confusing them (thread is case in point). If we're going to cater to ignorance, then the message should reflect the situation. Thus IMO, this is what ***should*** happen: Definition in rc.conf Behaviour/result ----------------------- ------------------------------------------- myprog_enable="yes" emit no warnings, service should run myprog_enable="no" emit no warnings, service should not run myprog_enable="abc123" emit a warning, service should not run emit no warnings, service should not run It's too bad FreeBSD doesn't have a real services framework like Solaris's smf/svccfg/svcs/svcadm, which in itself alleviates this entire situation. Services are registered with svccfg during installation; there's no config file, thus no chance of a situation. This software also comes to mind (folks who think systemd is a great solution should read the 2nd link): http://www.skarnet.org/software/s6/index.html http://www.skarnet.org/software/s6/why.html -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Feb 16 11:44:43 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 179EB875 for ; Sat, 16 Feb 2013 11:44:43 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward2h.mail.yandex.net (forward2h.mail.yandex.net [IPv6:2a02:6b8:0:f05::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2C659725 for ; Sat, 16 Feb 2013 11:44:41 +0000 (UTC) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward2h.mail.yandex.net (Yandex) with ESMTP id E673B70115C; Sat, 16 Feb 2013 15:44:37 +0400 (MSK) Received: from smtp1h.mail.yandex.net (localhost [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id 997F413402CA; Sat, 16 Feb 2013 15:44:37 +0400 (MSK) Received: from 87.249.28.58.tel.ru (87.249.28.58.tel.ru [87.249.28.58]) by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id ibTuPEp2-ibTuLYwt; Sat, 16 Feb 2013 15:44:37 +0400 Message-ID: <511F711D.4000306@passap.ru> Date: Sat, 16 Feb 2013 15:44:29 +0400 From: Boris Samorodov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: some issues with /usr/sbin/service References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com> <20130215212020.GA17516@icarus.home.lan> <20130215213257.GA20155@icarus.home.lan> <511F4205.50509@passap.ru> <20130216092133.GA31449@icarus.home.lan> In-Reply-To: <20130216092133.GA31449@icarus.home.lan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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, 16 Feb 2013 11:44:43 -0000 16.02.2013 13:21, Jeremy Chadwick пишет: > On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: >> 16.02.2013 01:32, Jeremy Chadwick ??????????: >> >>> Follow up -- I read Alfred's most recent mail. Lo and behold, I find >>> this in /var/log/messages (but such did not come to my terminal): >>> >>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). >>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not set properly - see rc.conf(5). >>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). >>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). >>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). >>> >>> Cute. Agreed -- this is unacceptable on two levels (as I see it): [...] >>> 2) These messages should not be displayed at all (i.e. lack of an >>> xxx_enable variable should imply xxx_enable="no"). >> >> I see this message as one more level of supervision. >> >> If undefined at /etc/make.conf the value of xxx_enable is "no" from the >> system's POV (i.e. the service is not strarted). From the >> admininstrators's POV the port was installed BUT is not used. It's up >> to admininstrator whether it's OK or not -- just let him remind. > > I believe the point you're trying to make is that the warning in > question should 'act as a reminder to the administrator that they need > to set xxx_enable="yes" in rc.conf'. > > If not: please explain if you could what you mean, because I don't > understand. That's it. But I call it "one more level of supervision" on purpose. There may be many sisadmins at one system and there may be many systems at one sysadmin. We are humans and make mistakes. One more level of supervision won't hurt. > If so: I strongly disagree with this method of approach, as what you've > proposed is a borderline straw man argument. Got ypour POV. > Reminding the admin to set xxx_enable is presently done inside most > ports' pkg-message. IMO, this should really be done inside bsd.port.mk > when USE_RC_SUBR is used, emitting a message during install that says > something like: > > To enable the xxx service, please add the following to /etc/rc.conf: > xxx_enable="yes" > > Of course, I don't know if this would work for packages. > > The current message for is this: > > WARNING: $xxx_enable is not set properly - see rc.conf(5). > > The message is entirely misleading for this specific situation; it isn't > "reminding" an administrator -- if anything it's confusing them (thread > is case in point). If we're going to cater to ignorance, then the > message should reflect the situation. "The message is is entirely misleading" -- yes, agreed! It should be reworded. ;-) > Thus IMO, this is what ***should*** happen: > > Definition in rc.conf Behaviour/result > ----------------------- ------------------------------------------- > myprog_enable="yes" emit no warnings, service should run > myprog_enable="no" emit no warnings, service should not run > myprog_enable="abc123" emit a warning, service should not run > emit no warnings, service should not run As I've said for system it is already that. But warnings are for humans. And I think that case 2) and 4) are entirely different. I'd rather see the current behavour at 4) but with better explanation. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-stable@FreeBSD.ORG Sat Feb 16 16:46:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1F904A64 for ; Sat, 16 Feb 2013 16:46:23 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ia0-x230.google.com (ia-in-x0230.1e100.net [IPv6:2607:f8b0:4001:c02::230]) by mx1.freebsd.org (Postfix) with ESMTP id E44D124A for ; Sat, 16 Feb 2013 16:46:22 +0000 (UTC) Received: by mail-ia0-f176.google.com with SMTP id i18so4054372iac.7 for ; Sat, 16 Feb 2013 08:46:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=I/TqAYs5vEr5bboqJo/UIOVXh48dy88x/eUvuotIDqo=; b=WvWxPDX2FMCAK5A6oVIcme7tSjR11+29V6U5Uf930iLXLf/flV4Do8TfnzabdX+1tJ /RiZBioRXhzddxrAYN88KgKJ0fzgHIiRmln0X5YvNkRWBS+Xa8SNrDO0E0z2I8zL2jHu D0qC+dfODKrcotmNJ7lRYyT743D0M6Beej4rOu90B59e9whLpS59TyQjTCqitZwSoLKP SjuDDRgs9xJ+ifEY99EYHXM4eUDYbrhcSnD40HS/UNqPTsWvor7dvknOnDSf25nVWgjG ZaIixceMyPVBH7oayxXbjyw1AigHzvBTs9qVW4tNflTZzOSjVVkbuBEAAL28c55lrrS9 IdFA== MIME-Version: 1.0 X-Received: by 10.50.7.231 with SMTP id m7mr5177935iga.0.1361033182029; Sat, 16 Feb 2013 08:46:22 -0800 (PST) Received: by 10.64.63.12 with HTTP; Sat, 16 Feb 2013 08:46:21 -0800 (PST) Received: by 10.64.63.12 with HTTP; Sat, 16 Feb 2013 08:46:21 -0800 (PST) In-Reply-To: <20130216092133.GA31449@icarus.home.lan> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com> <20130215212020.GA17516@icarus.home.lan> <20130215213257.GA20155@icarus.home.lan> <511F4205.50509@passap.ru> <20130216092133.GA31449@icarus.home.lan> Date: Sat, 16 Feb 2013 16:46:21 +0000 Message-ID: Subject: Re: some issues with /usr/sbin/service From: Chris Rees To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Boris Samorodov , FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 16:46:23 -0000 On 16 Feb 2013 09:21, "Jeremy Chadwick" wrote: > I do not know who maintains the rc(8) and rc.subr(8) framework, but > they've got their work cut out for them. That's an interesting comment.... Care to guess at the obvious answer? :) No-one actively maintains the infrastructure, though there are some knowledgeable and generous individuals who will review patches sent to rc@. Chris From owner-freebsd-stable@FreeBSD.ORG Sat Feb 16 17:06: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]) by hub.freebsd.org (Postfix) with ESMTP id 2DB51FE7 for ; Sat, 16 Feb 2013 17:06:38 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.freebsd.org (Postfix) with ESMTP id D79482DE for ; Sat, 16 Feb 2013 17:06:37 +0000 (UTC) Received: from dagger.cc.vt.edu (dagger.cc.vt.edu [198.82.163.114]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id r1GH5xKe029853; Sat, 16 Feb 2013 12:05:59 -0500 Received: from auth3.smtp.vt.edu (EHLO auth3.smtp.vt.edu) ([198.82.161.152]) by dagger.cc.vt.edu (MOS 4.3.3-GA FastPath queued) with ESMTP id YRU37942; Sat, 16 Feb 2013 12:05:58 -0500 (EST) Received: from macbook.chumby.lan (c-98-249-9-133.hsd1.va.comcast.net [98.249.9.133]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id r1GH5v3u000580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 16 Feb 2013 12:05:57 -0500 Subject: Re: some issues with /usr/sbin/service Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Paul Mather In-Reply-To: <20130216092133.GA31449@icarus.home.lan> Date: Sat, 16 Feb 2013 12:05:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1FD54589-7C32-47B5-A400-02FEE1459B02@gromit.dlib.vt.edu> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com> <20130215212020.GA17516@icarus.home.lan> <20130215213257.GA20155@icarus.home.lan> <511F4205.50509@passap.ru> <20130216092133.GA31449@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1283) X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu paul@gromit.dlib.vt.edu 5 none X-Junkmail-Status: score=10/50, host=dagger.cc.vt.edu X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A020209.511FBC77.0045,ss=1,re=0.000,fgs=0, ip=98.249.9.133, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=single engine X-Junkmail-IWF: false Cc: freebsd-stable@FreeBSD.org, Boris Samorodov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Feb 2013 17:06:38 -0000 On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote: > On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: >> 16.02.2013 01:32, Jeremy Chadwick ??????????: >>=20 >>> Follow up -- I read Alfred's most recent mail. Lo and behold, I = find >>> this in /var/log/messages (but such did not come to my terminal): >>>=20 >>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: = $svnserve_enable is not set properly - see rc.conf(5). >>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: = $smartd_enable is not set properly - see rc.conf(5). >>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: = $rsyncd_enable is not set properly - see rc.conf(5). >>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: = $htcacheclean_enable is not set properly - see rc.conf(5). >>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: = $fetchmail_enable is not set properly - see rc.conf(5). >>>=20 >>> Cute. Agreed -- this is unacceptable on two levels (as I see it): >>>=20 >>> 1) These messages should be going to stdout or stderr in some way, = so >>> honestly logger(8) should be called with the "-s" flag (IMO). >>=20 >> Fully agreed here. >=20 > It turns out logger -s has no effect, just like how the echo 1>&2 > statements in warn() and err() have no effect either (these should be > outputting the warnings in question to stderr) -- see rc.subr's source > for what I'm referring to. >=20 > Gary and I have been discussing this off-list and the reason has been > found: service(8) has this code in it: >=20 > checkyesno $rcvar 2>/dev/null && echo $file >=20 > This explains why there's no warn() or err() output on the terminal -- > it's being redirected to /dev/null prior. >=20 > I do not know who maintains the rc(8) and rc.subr(8) framework, but > they've got their work cut out for them. >=20 > (Note: the echo statements in warn() and err() could be replaced with > "logger -s" as I said; this would allow the "echo 1>&2" to be removed) >=20 >>> 2) These messages should not be displayed at all (i.e. lack of an >>> xxx_enable variable should imply xxx_enable=3D"no"). >>=20 >> I see this message as one more level of supervision. >>=20 >> If undefined at /etc/make.conf the value of xxx_enable is "no" from = the >> system's POV (i.e. the service is not strarted). =46rom the >> admininstrators's POV the port was installed BUT is not used. It's up >> to admininstrator whether it's OK or not -- just let him remind. >=20 > I believe the point you're trying to make is that the warning in > question should 'act as a reminder to the administrator that they need > to set xxx_enable=3D"yes" in rc.conf'. >=20 > If not: please explain if you could what you mean, because I don't > understand. >=20 > If so: I strongly disagree with this method of approach, as what = you've > proposed is a borderline straw man argument. >=20 > Reminding the admin to set xxx_enable is presently done inside most > ports' pkg-message. IMO, this should really be done inside = bsd.port.mk > when USE_RC_SUBR is used, emitting a message during install that says > something like: >=20 > To enable the xxx service, please add the following to /etc/rc.conf: > xxx_enable=3D"yes" >=20 > Of course, I don't know if this would work for packages. >=20 > The current message for is this: >=20 > WARNING: $xxx_enable is not set properly - see rc.conf(5). >=20 > The message is entirely misleading for this specific situation; it = isn't > "reminding" an administrator -- if anything it's confusing them = (thread > is case in point). If we're going to cater to ignorance, then the > message should reflect the situation. >=20 > Thus IMO, this is what ***should*** happen: >=20 > Definition in rc.conf Behaviour/result > ----------------------- ------------------------------------------- > myprog_enable=3D"yes" emit no warnings, service should run > myprog_enable=3D"no" emit no warnings, service should not run > myprog_enable=3D"abc123" emit a warning, service should not run > emit no warnings, service should not run I think case 4 ("") is a case where a warning should be = emitted because it is arguably not immediately apparent what will = actually happen if no definition is present. In the case of services in = the base OS it is well-defined: every service should have an explicit = default in /etc/defaults/rc.conf that you can easily consult to know = definitively what will happen with that service. (If it doesn't, that = is a bug, IMHO.) For ports, the case is not so clear. There is a general trend for the = port rc.d script to default its respective xxx_enable explicitly to = "NO". But it is not a universal rule that "no definition" =3D default = to "NO". The net/avahi-app port, for example, doesn't default to "NO" = if xxx_enable is not set: it defaults to whatever the gnome_enable = setting is defined to be. For the base OS, I agree with your case 4; for the land of ports, I = don't think the answer is so cut and dried. That is why I think the = warning is useful: it reminds admins to look at the service in question = and make a firm decision of their own as to whether it should explicitly = be turned on or off. It is a reminder to configure the service properly = and remove ambiguity. (I also personally find the warnings a useful reminder of services that = are candidates for removal on the grounds that they appear never to have = been configured.) Cheers, Paul.= From owner-freebsd-stable@FreeBSD.ORG Sat Feb 16 17:39:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C89BD4CA for ; Sat, 16 Feb 2013 17:39:27 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id 852B666B for ; Sat, 16 Feb 2013 17:39:27 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id 17so5846441iea.40 for ; Sat, 16 Feb 2013 09:39:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ElDM1JMeqDZl2cqvwK7REnY32V2Aec0svqPpxLo0Hv0=; b=pnZu83JNUhneZ13GJQ71sXLEAENEKRd9ytyHsMzUeA4hypxRAse0RCLCIX5Yf6uDCz LgELty0L6eQZkGZt2Mzgm40CG3fSA1ixpQlFpmTJmS1fYur/wKM3k0KG8hJy++lifH5i +WBTEikYujBbHoVz1VMhlHYp4RwOrOEFptqm6xNgTS98HEm1p8QxGgAtNj3NgLDlgw7n 1Of4wB5AG9oFU0mWev9eqrgGIqpJZ7Ao1vfBfAwPZSCqW97+6opqFY2hLO+4tjQB6NK6 Usl2xCmBMhymymbMGGfJb47n1hD+kkT1hRCkgoNmDbxemVzrQ9rouFWLB507YOUoWVY9 HQ1g== X-Received: by 10.50.214.10 with SMTP id nw10mr4296650igc.15.1361036367215; Sat, 16 Feb 2013 09:39:27 -0800 (PST) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.64.63.12 with HTTP; Sat, 16 Feb 2013 09:38:56 -0800 (PST) In-Reply-To: <1FD54589-7C32-47B5-A400-02FEE1459B02@gromit.dlib.vt.edu> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com> <20130215212020.GA17516@icarus.home.lan> <20130215213257.GA20155@icarus.home.lan> <511F4205.50509@passap.ru> <20130216092133.GA31449@icarus.home.lan> <1FD54589-7C32-47B5-A400-02FEE1459B02@gromit.dlib.vt.edu> From: Chris Rees Date: Sat, 16 Feb 2013 17:38:56 +0000 X-Google-Sender-Auth: 9ey589VsNysmBZ9qvksbh7vg4VE Message-ID: Subject: Re: some issues with /usr/sbin/service To: Paul Mather Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jeremy Chadwick , Boris Samorodov , FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 17:39:27 -0000 On 16 February 2013 17:05, Paul Mather wrote: > On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote: > >> On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: >>> 16.02.2013 01:32, Jeremy Chadwick ??????????: >>> >>>> Follow up -- I read Alfred's most recent mail. Lo and behold, I find >>>> this in /var/log/messages (but such did not come to my terminal): >>>> >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enab= le is not set properly - see rc.conf(5). >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable= is not set properly - see rc.conf(5). >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable= is not set properly - see rc.conf(5). >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_= enable is not set properly - see rc.conf(5). >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_ena= ble is not set properly - see rc.conf(5). >>>> >>>> Cute. Agreed -- this is unacceptable on two levels (as I see it): >>>> >>>> 1) These messages should be going to stdout or stderr in some way, so >>>> honestly logger(8) should be called with the "-s" flag (IMO). >>> >>> Fully agreed here. >> >> It turns out logger -s has no effect, just like how the echo 1>&2 >> statements in warn() and err() have no effect either (these should be >> outputting the warnings in question to stderr) -- see rc.subr's source >> for what I'm referring to. >> >> Gary and I have been discussing this off-list and the reason has been >> found: service(8) has this code in it: >> >> checkyesno $rcvar 2>/dev/null && echo $file >> >> This explains why there's no warn() or err() output on the terminal -- >> it's being redirected to /dev/null prior. >> >> I do not know who maintains the rc(8) and rc.subr(8) framework, but >> they've got their work cut out for them. >> >> (Note: the echo statements in warn() and err() could be replaced with >> "logger -s" as I said; this would allow the "echo 1>&2" to be removed) >> >>>> 2) These messages should not be displayed at all (i.e. lack of an >>>> xxx_enable variable should imply xxx_enable=3D"no"). >>> >>> I see this message as one more level of supervision. >>> >>> If undefined at /etc/make.conf the value of xxx_enable is "no" from the >>> system's POV (i.e. the service is not strarted). From the >>> admininstrators's POV the port was installed BUT is not used. It's up >>> to admininstrator whether it's OK or not -- just let him remind. >> >> I believe the point you're trying to make is that the warning in >> question should 'act as a reminder to the administrator that they need >> to set xxx_enable=3D"yes" in rc.conf'. >> >> If not: please explain if you could what you mean, because I don't >> understand. >> >> If so: I strongly disagree with this method of approach, as what you've >> proposed is a borderline straw man argument. >> >> Reminding the admin to set xxx_enable is presently done inside most >> ports' pkg-message. IMO, this should really be done inside bsd.port.mk >> when USE_RC_SUBR is used, emitting a message during install that says >> something like: >> >> To enable the xxx service, please add the following to /etc/rc.conf: >> xxx_enable=3D"yes" >> >> Of course, I don't know if this would work for packages. >> >> The current message for is this: >> >> WARNING: $xxx_enable is not set properly - see rc.conf(5). >> >> The message is entirely misleading for this specific situation; it isn't >> "reminding" an administrator -- if anything it's confusing them (thread >> is case in point). If we're going to cater to ignorance, then the >> message should reflect the situation. >> >> Thus IMO, this is what ***should*** happen: >> >> Definition in rc.conf Behaviour/result >> ----------------------- ------------------------------------------- >> myprog_enable=3D"yes" emit no warnings, service should run >> myprog_enable=3D"no" emit no warnings, service should not run >> myprog_enable=3D"abc123" emit a warning, service should not run >> emit no warnings, service should not run > > > I think case 4 ("") is a case where a warning should be em= itted because it is arguably not immediately apparent what will actually ha= ppen if no definition is present. In the case of services in the base OS i= t is well-defined: every service should have an explicit default in /etc/de= faults/rc.conf that you can easily consult to know definitively what will h= appen with that service. (If it doesn't, that is a bug, IMHO.) > > For ports, the case is not so clear. There is a general trend for the po= rt rc.d script to default its respective xxx_enable explicitly to "NO". Bu= t it is not a universal rule that "no definition" =3D default to "NO". The= net/avahi-app port, for example, doesn't default to "NO" if xxx_enable is = not set: it defaults to whatever the gnome_enable setting is defined to be. With few exceptions, it should be considered a rule that ports rc scripts contain: : ${xxx_enable=3Dno} to avoid this. If you see any ports that don't define the _enable variable at all, they are wrong and need fixing. Chris From owner-freebsd-stable@FreeBSD.ORG Sat Feb 16 18:09:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 683FDE53; Sat, 16 Feb 2013 18:09:04 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 12BDD74E; Sat, 16 Feb 2013 18:09:04 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U6mC4-000KT5-1O; Sat, 16 Feb 2013 13:09:00 -0500 Date: Sat, 16 Feb 2013 13:08:59 -0500 From: Gary Palmer To: Chris Rees Subject: Re: some issues with /usr/sbin/service Message-ID: <20130216180859.GF85777@in-addr.com> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com> <20130215212020.GA17516@icarus.home.lan> <20130215213257.GA20155@icarus.home.lan> <511F4205.50509@passap.ru> <20130216092133.GA31449@icarus.home.lan> <1FD54589-7C32-47B5-A400-02FEE1459B02@gromit.dlib.vt.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: Jeremy Chadwick , FreeBSD , Boris Samorodov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Feb 2013 18:09:04 -0000 On Sat, Feb 16, 2013 at 05:38:56PM +0000, Chris Rees wrote: > On 16 February 2013 17:05, Paul Mather wrote: > > On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote: > > > >> On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: > >>> 16.02.2013 01:32, Jeremy Chadwick ??????????: > >>> > >>>> Follow up -- I read Alfred's most recent mail. Lo and behold, I find > >>>> this in /var/log/messages (but such did not come to my terminal): > >>>> > >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). > >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not set properly - see rc.conf(5). > >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). > >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). > >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). > >>>> > >>>> Cute. Agreed -- this is unacceptable on two levels (as I see it): > >>>> > >>>> 1) These messages should be going to stdout or stderr in some way, so > >>>> honestly logger(8) should be called with the "-s" flag (IMO). > >>> > >>> Fully agreed here. > >> > >> It turns out logger -s has no effect, just like how the echo 1>&2 > >> statements in warn() and err() have no effect either (these should be > >> outputting the warnings in question to stderr) -- see rc.subr's source > >> for what I'm referring to. > >> > >> Gary and I have been discussing this off-list and the reason has been > >> found: service(8) has this code in it: > >> > >> checkyesno $rcvar 2>/dev/null && echo $file > >> > >> This explains why there's no warn() or err() output on the terminal -- > >> it's being redirected to /dev/null prior. > >> > >> I do not know who maintains the rc(8) and rc.subr(8) framework, but > >> they've got their work cut out for them. > >> > >> (Note: the echo statements in warn() and err() could be replaced with > >> "logger -s" as I said; this would allow the "echo 1>&2" to be removed) > >> > >>>> 2) These messages should not be displayed at all (i.e. lack of an > >>>> xxx_enable variable should imply xxx_enable="no"). > >>> > >>> I see this message as one more level of supervision. > >>> > >>> If undefined at /etc/make.conf the value of xxx_enable is "no" from the > >>> system's POV (i.e. the service is not strarted). From the > >>> admininstrators's POV the port was installed BUT is not used. It's up > >>> to admininstrator whether it's OK or not -- just let him remind. > >> > >> I believe the point you're trying to make is that the warning in > >> question should 'act as a reminder to the administrator that they need > >> to set xxx_enable="yes" in rc.conf'. > >> > >> If not: please explain if you could what you mean, because I don't > >> understand. > >> > >> If so: I strongly disagree with this method of approach, as what you've > >> proposed is a borderline straw man argument. > >> > >> Reminding the admin to set xxx_enable is presently done inside most > >> ports' pkg-message. IMO, this should really be done inside bsd.port.mk > >> when USE_RC_SUBR is used, emitting a message during install that says > >> something like: > >> > >> To enable the xxx service, please add the following to /etc/rc.conf: > >> xxx_enable="yes" > >> > >> Of course, I don't know if this would work for packages. > >> > >> The current message for is this: > >> > >> WARNING: $xxx_enable is not set properly - see rc.conf(5). > >> > >> The message is entirely misleading for this specific situation; it isn't > >> "reminding" an administrator -- if anything it's confusing them (thread > >> is case in point). If we're going to cater to ignorance, then the > >> message should reflect the situation. > >> > >> Thus IMO, this is what ***should*** happen: > >> > >> Definition in rc.conf Behaviour/result > >> ----------------------- ------------------------------------------- > >> myprog_enable="yes" emit no warnings, service should run > >> myprog_enable="no" emit no warnings, service should not run > >> myprog_enable="abc123" emit a warning, service should not run > >> emit no warnings, service should not run > > > > > > I think case 4 ("") is a case where a warning should be emitted because it is arguably not immediately apparent what will actually happen if no definition is present. In the case of services in the base OS it is well-defined: every service should have an explicit default in /etc/defaults/rc.conf that you can easily consult to know definitively what will happen with that service. (If it doesn't, that is a bug, IMHO.) > > > > For ports, the case is not so clear. There is a general trend for the port rc.d script to default its respective xxx_enable explicitly to "NO". But it is not a universal rule that "no definition" = default to "NO". The net/avahi-app port, for example, doesn't default to "NO" if xxx_enable is not set: it defaults to whatever the gnome_enable setting is defined to be. > > With few exceptions, it should be considered a rule that ports rc > scripts contain: > > : ${xxx_enable=no} > > to avoid this. If you see any ports that don't define the _enable > variable at all, they are wrong and need fixing. Except the 'service' command doesn't parse the individual ports rc.d script so the default is never found. It relies purely on rc.conf and rc.conf.local settings. So no matter if the port has : ${xxx_enable=no} or not, 'service -e' will still spit out the warnings Not loading the individual ports files is probably done for two reasons I can think of - performance, and safety (in case the rc.d file is bad for some reason). However it leads to these rather irritating warnings, especially when you find them later and you don't know what you did to cause them. I was away to suggest that having /usr/local/etc/rc.conf.d would help as ports could then specify their defaults safely without having to do file rewrites, however that appears to be only looked at in load_rc_config(), and 'service -e' bypasses that as well by doing load_rc_config 'XXX' so only /usr/local/etc/rc.conf.d/xxx would be looked at. Gary From owner-freebsd-stable@FreeBSD.ORG Sat Feb 16 18:13:10 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 71FE0FA7; Sat, 16 Feb 2013 18:13:10 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 3D82978D; Sat, 16 Feb 2013 18:13:09 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa06.fnfis.com (8.14.5/8.14.5) with ESMTP id r1GID13Y017532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 16 Feb 2013 12:13:01 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.02.0309.002; Sat, 16 Feb 2013 12:13:00 -0600 From: "Teske, Devin" To: Gary Palmer , Chris Rees Subject: RE: some issues with /usr/sbin/service Thread-Topic: some issues with /usr/sbin/service Thread-Index: AQHOC2gkfN63QqWr4EOkxrCp80so8Zh7JCwAgACP5ACAAB45AIAAA4aAgAC1xoCAABA1gIAAgcCAgAAJOACAAAhlgP//m9In Date: Sat, 16 Feb 2013 18:13:00 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201EAA456@ltcfiswmsgmb21> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com> <20130215212020.GA17516@icarus.home.lan> <20130215213257.GA20155@icarus.home.lan> <511F4205.50509@passap.ru> <20130216092133.GA31449@icarus.home.lan> <1FD54589-7C32-47B5-A400-02FEE1459B02@gromit.dlib.vt.edu> , <20130216180859.GF85777@in-addr.com> In-Reply-To: <20130216180859.GF85777@in-addr.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-02-16_04:2013-02-15,2013-02-16,1970-01-01 signatures=0 Cc: Jeremy Chadwick , Boris Samorodov , FreeBSD , "Teske, Devin" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Feb 2013 18:13:10 -0000 (sorry for top-post ... dumb client software) Am I missing something in this entire thread or... Why not utilize the oft-neglected "/etc/rc.conf.d" directory? Example? My own "vimage" package which installs: /etc/rc.conf.d/vimage /etc/rc.d/vimage The /etc/rc.conf.d file is a segment of what should appear in /etc/defaults= /rc.conf.d and is loaded whenever a service is loaded. The /etc/rc.conf.d a= cts as a set of underrides just like /etc/defaults/rc.conf does for the res= t of the rc system. --=20 Devin ________________________________________ From: owner-freebsd-stable@freebsd.org [owner-freebsd-stable@freebsd.org] o= n behalf of Gary Palmer [gpalmer@freebsd.org] Sent: Saturday, February 16, 2013 10:08 AM To: Chris Rees Cc: Jeremy Chadwick; FreeBSD; Boris Samorodov Subject: Re: some issues with /usr/sbin/service On Sat, Feb 16, 2013 at 05:38:56PM +0000, Chris Rees wrote: > On 16 February 2013 17:05, Paul Mather wrote: > > On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote: > > > >> On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: > >>> 16.02.2013 01:32, Jeremy Chadwick ??????????: > >>> > >>>> Follow up -- I read Alfred's most recent mail. Lo and behold, I find > >>>> this in /var/log/messages (but such did not come to my terminal): > >>>> > >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_en= able is not set properly - see rc.conf(5). > >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enab= le is not set properly - see rc.conf(5). > >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enab= le is not set properly - see rc.conf(5). > >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclea= n_enable is not set properly - see rc.conf(5). > >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_e= nable is not set properly - see rc.conf(5). > >>>> > >>>> Cute. Agreed -- this is unacceptable on two levels (as I see it): > >>>> > >>>> 1) These messages should be going to stdout or stderr in some way, so > >>>> honestly logger(8) should be called with the "-s" flag (IMO). > >>> > >>> Fully agreed here. > >> > >> It turns out logger -s has no effect, just like how the echo 1>&2 > >> statements in warn() and err() have no effect either (these should be > >> outputting the warnings in question to stderr) -- see rc.subr's source > >> for what I'm referring to. > >> > >> Gary and I have been discussing this off-list and the reason has been > >> found: service(8) has this code in it: > >> > >> checkyesno $rcvar 2>/dev/null && echo $file > >> > >> This explains why there's no warn() or err() output on the terminal -- > >> it's being redirected to /dev/null prior. > >> > >> I do not know who maintains the rc(8) and rc.subr(8) framework, but > >> they've got their work cut out for them. > >> > >> (Note: the echo statements in warn() and err() could be replaced with > >> "logger -s" as I said; this would allow the "echo 1>&2" to be removed) > >> > >>>> 2) These messages should not be displayed at all (i.e. lack of an > >>>> xxx_enable variable should imply xxx_enable=3D"no"). > >>> > >>> I see this message as one more level of supervision. > >>> > >>> If undefined at /etc/make.conf the value of xxx_enable is "no" from t= he > >>> system's POV (i.e. the service is not strarted). From the > >>> admininstrators's POV the port was installed BUT is not used. It's up > >>> to admininstrator whether it's OK or not -- just let him remind. > >> > >> I believe the point you're trying to make is that the warning in > >> question should 'act as a reminder to the administrator that they need > >> to set xxx_enable=3D"yes" in rc.conf'. > >> > >> If not: please explain if you could what you mean, because I don't > >> understand. > >> > >> If so: I strongly disagree with this method of approach, as what you've > >> proposed is a borderline straw man argument. > >> > >> Reminding the admin to set xxx_enable is presently done inside most > >> ports' pkg-message. IMO, this should really be done inside bsd.port.mk > >> when USE_RC_SUBR is used, emitting a message during install that says > >> something like: > >> > >> To enable the xxx service, please add the following to /etc/rc.conf: > >> xxx_enable=3D"yes" > >> > >> Of course, I don't know if this would work for packages. > >> > >> The current message for is this: > >> > >> WARNING: $xxx_enable is not set properly - see rc.conf(5). > >> > >> The message is entirely misleading for this specific situation; it isn= 't > >> "reminding" an administrator -- if anything it's confusing them (thread > >> is case in point). If we're going to cater to ignorance, then the > >> message should reflect the situation. > >> > >> Thus IMO, this is what ***should*** happen: > >> > >> Definition in rc.conf Behaviour/result > >> ----------------------- ------------------------------------------- > >> myprog_enable=3D"yes" emit no warnings, service should run > >> myprog_enable=3D"no" emit no warnings, service should not run > >> myprog_enable=3D"abc123" emit a warning, service should not run > >> emit no warnings, service should not run > > > > > > I think case 4 ("") is a case where a warning should be = emitted because it is arguably not immediately apparent what will actually = happen if no definition is present. In the case of services in the base OS= it is well-defined: every service should have an explicit default in /etc/= defaults/rc.conf that you can easily consult to know definitively what will= happen with that service. (If it doesn't, that is a bug, IMHO.) > > > > For ports, the case is not so clear. There is a general trend for the = port rc.d script to default its respective xxx_enable explicitly to "NO". = But it is not a universal rule that "no definition" =3D default to "NO". T= he net/avahi-app port, for example, doesn't default to "NO" if xxx_enable i= s not set: it defaults to whatever the gnome_enable setting is defined to b= e. > > With few exceptions, it should be considered a rule that ports rc > scripts contain: > > : ${xxx_enable=3Dno} > > to avoid this. If you see any ports that don't define the _enable > variable at all, they are wrong and need fixing. Except the 'service' command doesn't parse the individual ports rc.d script so the default is never found. It relies purely on rc.conf and rc.conf.local settings. So no matter if the port has : ${xxx_enable=3Dno} or not, 'service -e' will still spit out the warnings Not loading the individual ports files is probably done for two reasons I can think of - performance, and safety (in case the rc.d file is bad for some reason). However it leads to these rather irritating warnings, especially when you find them later and you don't know what you did to cause them. I was away to suggest that having /usr/local/etc/rc.conf.d would help as ports could then specify their defaults safely without having to do file rewrites, however that appears to be only looked at in load_rc_config(), and 'service -e' bypasses that as well by doing load_rc_config 'XXX' so only /usr/local/etc/rc.conf.d/xxx would be looked at. Gary _______________________________________________ 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" _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-stable@FreeBSD.ORG Sat Feb 16 18:24:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 063EC37B; Sat, 16 Feb 2013 18:24:52 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8967E6; Sat, 16 Feb 2013 18:24:51 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id c13so5897021ieb.23 for ; Sat, 16 Feb 2013 10:24:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=KaNkbkvdryqXPt/D7I3cIlINtnwBk2yV6K8+5w33rgE=; b=TryLK6rJz9zeSwqA+FXE8RxFDY6pwxpEpOpq4MS6fKKpxv7Yqcc4dTzodpy8siidbJ E585XiOAHRBRJkDhkXhlhGgOOzpZxNvYyXub+iV0vjyd46PPZdG2YULIwn9tL18fBy/1 gCTjrC3WSWtUr4MV7cX8079UgxRvcoAr2lpchv6YE5I8TBEBudWPhXcpKjSzqXUDJKos IogJ6TVOpEiEbuTCOWaurguevAh7eJzOcFx2lFiRwTQ6F3ePnm/gUfRMnCyqDONlAeTr /JtE31EDlIFgpDYnizJ8brYhrwSw/CuJM0Gmedhp5WiaOd1xbKToXtUpmu4kiuDUTjem h47Q== X-Received: by 10.50.13.175 with SMTP id i15mr4223440igc.75.1361039091202; Sat, 16 Feb 2013 10:24:51 -0800 (PST) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.64.63.12 with HTTP; Sat, 16 Feb 2013 10:24:20 -0800 (PST) In-Reply-To: <20130216180859.GF85777@in-addr.com> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com> <20130215212020.GA17516@icarus.home.lan> <20130215213257.GA20155@icarus.home.lan> <511F4205.50509@passap.ru> <20130216092133.GA31449@icarus.home.lan> <1FD54589-7C32-47B5-A400-02FEE1459B02@gromit.dlib.vt.edu> <20130216180859.GF85777@in-addr.com> From: Chris Rees Date: Sat, 16 Feb 2013 18:24:20 +0000 X-Google-Sender-Auth: QwuXglDvBmeLH9mY7ASPkryKYp0 Message-ID: Subject: Re: some issues with /usr/sbin/service To: Gary Palmer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jeremy Chadwick , FreeBSD , Boris Samorodov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Feb 2013 18:24:52 -0000 On 16 February 2013 18:08, Gary Palmer wrote: > On Sat, Feb 16, 2013 at 05:38:56PM +0000, Chris Rees wrote: >> On 16 February 2013 17:05, Paul Mather wrote: >> > On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote: >> > >> >> On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: >> >>> 16.02.2013 01:32, Jeremy Chadwick ??????????: >> >>> >> >>>> Follow up -- I read Alfred's most recent mail. Lo and behold, I fi= nd >> >>>> this in /var/log/messages (but such did not come to my terminal): >> >>>> >> >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_e= nable is not set properly - see rc.conf(5). >> >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_ena= ble is not set properly - see rc.conf(5). >> >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_ena= ble is not set properly - see rc.conf(5). >> >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcachecle= an_enable is not set properly - see rc.conf(5). >> >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_= enable is not set properly - see rc.conf(5). >> >>>> >> >>>> Cute. Agreed -- this is unacceptable on two levels (as I see it): >> >>>> >> >>>> 1) These messages should be going to stdout or stderr in some way, = so >> >>>> honestly logger(8) should be called with the "-s" flag (IMO). >> >>> >> >>> Fully agreed here. >> >> >> >> It turns out logger -s has no effect, just like how the echo 1>&2 >> >> statements in warn() and err() have no effect either (these should be >> >> outputting the warnings in question to stderr) -- see rc.subr's sourc= e >> >> for what I'm referring to. >> >> >> >> Gary and I have been discussing this off-list and the reason has been >> >> found: service(8) has this code in it: >> >> >> >> checkyesno $rcvar 2>/dev/null && echo $file >> >> >> >> This explains why there's no warn() or err() output on the terminal -= - >> >> it's being redirected to /dev/null prior. >> >> >> >> I do not know who maintains the rc(8) and rc.subr(8) framework, but >> >> they've got their work cut out for them. >> >> >> >> (Note: the echo statements in warn() and err() could be replaced with >> >> "logger -s" as I said; this would allow the "echo 1>&2" to be removed= ) >> >> >> >>>> 2) These messages should not be displayed at all (i.e. lack of an >> >>>> xxx_enable variable should imply xxx_enable=3D"no"). >> >>> >> >>> I see this message as one more level of supervision. >> >>> >> >>> If undefined at /etc/make.conf the value of xxx_enable is "no" from = the >> >>> system's POV (i.e. the service is not strarted). From the >> >>> admininstrators's POV the port was installed BUT is not used. It's u= p >> >>> to admininstrator whether it's OK or not -- just let him remind. >> >> >> >> I believe the point you're trying to make is that the warning in >> >> question should 'act as a reminder to the administrator that they nee= d >> >> to set xxx_enable=3D"yes" in rc.conf'. >> >> >> >> If not: please explain if you could what you mean, because I don't >> >> understand. >> >> >> >> If so: I strongly disagree with this method of approach, as what you'= ve >> >> proposed is a borderline straw man argument. >> >> >> >> Reminding the admin to set xxx_enable is presently done inside most >> >> ports' pkg-message. IMO, this should really be done inside bsd.port.= mk >> >> when USE_RC_SUBR is used, emitting a message during install that says >> >> something like: >> >> >> >> To enable the xxx service, please add the following to /etc/rc.conf: >> >> xxx_enable=3D"yes" >> >> >> >> Of course, I don't know if this would work for packages. >> >> >> >> The current message for is this: >> >> >> >> WARNING: $xxx_enable is not set properly - see rc.conf(5). >> >> >> >> The message is entirely misleading for this specific situation; it is= n't >> >> "reminding" an administrator -- if anything it's confusing them (thre= ad >> >> is case in point). If we're going to cater to ignorance, then the >> >> message should reflect the situation. >> >> >> >> Thus IMO, this is what ***should*** happen: >> >> >> >> Definition in rc.conf Behaviour/result >> >> ----------------------- ------------------------------------------- >> >> myprog_enable=3D"yes" emit no warnings, service should run >> >> myprog_enable=3D"no" emit no warnings, service should not run >> >> myprog_enable=3D"abc123" emit a warning, service should not run >> >> emit no warnings, service should not run >> > >> > >> > I think case 4 ("") is a case where a warning should be= emitted because it is arguably not immediately apparent what will actually= happen if no definition is present. In the case of services in the base O= S it is well-defined: every service should have an explicit default in /etc= /defaults/rc.conf that you can easily consult to know definitively what wil= l happen with that service. (If it doesn't, that is a bug, IMHO.) >> > >> > For ports, the case is not so clear. There is a general trend for the= port rc.d script to default its respective xxx_enable explicitly to "NO". = But it is not a universal rule that "no definition" =3D default to "NO". = The net/avahi-app port, for example, doesn't default to "NO" if xxx_enable = is not set: it defaults to whatever the gnome_enable setting is defined to = be. >> >> With few exceptions, it should be considered a rule that ports rc >> scripts contain: >> >> : ${xxx_enable=3Dno} >> >> to avoid this. If you see any ports that don't define the _enable >> variable at all, they are wrong and need fixing. > > Except the 'service' command doesn't parse the individual ports rc.d > script so the default is never found. It relies purely on rc.conf and > rc.conf.local settings. > > So no matter if the port has > > : ${xxx_enable=3Dno} > > or not, 'service -e' will still spit out the warnings > > Not loading the individual ports files is probably done for two reasons > I can think of - performance, and safety (in case the rc.d file is bad > for some reason). However it leads to these rather irritating > warnings, especially when you find them later and you don't know what > you did to cause them. > > I was away to suggest that having /usr/local/etc/rc.conf.d would help > as ports could then specify their defaults safely without having to do > file rewrites, however that appears to be only looked at in > load_rc_config(), and 'service -e' bypasses that as well by doing > > load_rc_config 'XXX' > > so only /usr/local/etc/rc.conf.d/xxx would be looked at. Yes, OK. A variation on Alfred's checkyes patch is at [1]. I have not made it into a function deliberately because this is already rc idiom as used in other rc scripts where a warning is not necessary, and also because it is very rarely the right thing to do (i.e. it would be tempting to overuse it if it were a function). Chris [1] http://www.bayofrum.net/~crees/patches/service-no-logging.diff From owner-freebsd-stable@FreeBSD.ORG Sat Feb 16 18:25:33 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 56C3C47D for ; Sat, 16 Feb 2013 18:25:33 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by mx1.freebsd.org (Postfix) with ESMTP id E6E447FB for ; Sat, 16 Feb 2013 18:25:32 +0000 (UTC) Received: by mail-ee0-f43.google.com with SMTP id c50so2178718eek.30 for ; Sat, 16 Feb 2013 10:25:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gIKkZypgJkVINsr1xM++O0F0Awt+hmOfBQayjXLLMOk=; b=jKbBMy9WaEXEOTkRJU4n24gbnMK6pnNu76RaDTCOTyB3t6TPsrUpfEVEB/Ztpx6r4z HSlA53lPYa5L++xW2/GvzqN1cFSXZDQdCF3LBGRqQkPktCoy9I5lSp4lRtOydp3m1UGH Ce3/HbXaIpd1PIbro3iuDWzUFynXMz0WMnkVOyu4o21JFBgd9jkaS6XfwLL5v8pLs/Ft m2M/ksBo1ADevY9mON3rNQZvF/BUgjsNIfu6SqfdILEYpuomy8ptJAvobaFUzgGctxOb yecpCw64t5Q9loFzlbVVkjMHjxfPGCPFTANqAQoNpTpVeVYiiscXvH2J9kjR4KiJQx5k Ir3g== MIME-Version: 1.0 X-Received: by 10.14.207.200 with SMTP id n48mr23377834eeo.4.1361039126044; Sat, 16 Feb 2013 10:25:26 -0800 (PST) Received: by 10.223.177.7 with HTTP; Sat, 16 Feb 2013 10:25:25 -0800 (PST) In-Reply-To: <511CECCC.60400@grosbein.pp.ru> References: <511CECCC.60400@grosbein.pp.ru> Date: Sat, 16 Feb 2013 12:25:25 -0600 Message-ID: Subject: Re: i386: vm.pmap kernel local race condition From: Alan Cox To: Eugene Grosbein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: alc@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 18:25:33 -0000 On Thu, Feb 14, 2013 at 7:55 AM, Eugene Grosbein wrote: > Hi! > > I've got FreeBSD 8.3-STABLE/i386 server that can be reliably panicked > using just 'squid -k rotatelog' command. It seems the system suffers > from the problem described here: > > http://cxsecurity.com/issue/WLB-2010090156 > > I could not find any FreeBSD Security Advisory containing a fix. > > My server has 4G physical RAM (about 3.2G available) and runs > squid (about 110M VSS) with 500 ntlm_auth subprocesses. > Lesser number of ntlm_auth sometimes results in squid crash > as it sometimes has several hundreds requests per second to authorize > and is intolerant to exhaustion of free ntlm_auth. > > "squid -k rotatelog" at midnight results in crash: > > Feb 14 00:03:00 irl savecore: reboot after panic: get_pv_entry: increase > vm.pmap.shpgperproc > Feb 14 00:03:00 irl savecore: writing core to vmcore.1 > > Btw, I have coredump. > > vm.pmap.shpgperproc has default value (200) here, as well as m.v_free_min, > vm.v_free_reserved, and vm.v_free_target and KVA_PAGES. > > These crashes are pretty regular > > # last|fgrep reboot > reboot ~ Thu Feb 14 00:03 > reboot ~ Wed Feb 13 19:08 > reboot ~ Wed Feb 13 10:40 > reboot ~ Wed Feb 13 00:04 > reboot ~ Tue Feb 12 00:09 > reboot ~ Mon Feb 11 00:03 > reboot ~ Sun Feb 10 00:03 > reboot ~ Thu Feb 7 00:03 > reboot ~ Wed Feb 6 10:52 > reboot ~ Sun Feb 3 00:03 > reboot ~ Sat Feb 2 00:03 > > May this be considered as security problem? > Can it be fixed without switch to amd64? > I have only remote access to this production server, no serial console. > > Regardless of what that web site says, this is not really a race condition. Instead, you're exhausting a resource in the kernel because of the characteristics of your workload. The kernel tries to handle this gracefully, but in extreme cases, the kernel can't keep up with the demand. Have you simply tried doing as the panic message suggests, i.e., increase vm.pmap.shpgperproc? Alternatively, you can increase vm.pmap.pv_entry_max to more directly accomplish the same. That said, if possible, you should do as Adrian suggests and change your Squid configuration to not use 500 helper processes. That will allow a lot more of your machine's physical memory to go to caching data rather bookkeeping data structures in the kernel. Regards, Alan