From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 21 03:05:52 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ECFD01CC for ; Sun, 21 Jul 2013 03:05:52 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id CAC37ED2 for ; Sun, 21 Jul 2013 03:05:52 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id C1EF23AD8F; Sat, 20 Jul 2013 20:05:46 -0700 (PDT) From: "Ronald F. Guilmette" To: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon In-Reply-To: Date: Sat, 20 Jul 2013 20:05:46 -0700 Message-ID: <24574.1374375946@server1.tristatelogic.com> Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 03:05:53 -0000 In message =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= wrote: >It seems to work for me: Good. Just to make sure that we are clear, you are simply confirming what my bug report (bin/176713) said, i.e. that _without_ my fix, nc can prematurely truncate the output from some servers, whereas _with_ my fix this bad behaviour on the part of nc is cured... Is that correct? If so, thank you for confirming that my proposed fix produces the desired result. I feel compelled to say again that in actual point of fact, the way that I personally would prefer to see this problem resolved would *not* be to add a new option for the nc program. Rather, I think that it would actually be best simply to delete from the nc source code the one single line that is causing nc to stop its operation as soon as it receives an EOF from its stdin channel. If that line is simply deleted, then nc will instead wait until it receives an EOF from the remote server that it is talking to, and quite obviously, this change causes nc to produce output which is arguably more correct and which is certainly more useful that the prematurely truncated results that nc sometimes produces at present. >> P.P.S. I have just realized that yet one more critical enhancement for >> nc is called for, and I will be filing a separate and additional PR for >> that soon. I hope that someone will be able to take a look at that as >> soon as it is filed. > >Just out of curiosity. What is it about? Well, as it turns out, the additional "fix" that I had believed that I was going to propose for nc was not that critical after all... at least not for my current and immediate application(s). However it might still have some value in some cases anyway, so I will describe what I had in mind. Quite simply, I believe that it would be Good if the nc program had a new and additional option which, when used, would cause nc to refrain from sending any data _to_ the remote server until such time as it had received one entire line _from_ the remote server. Such an option could be useful when using nc to communicate with remote servers running certain protocols. For example, the rules of the SMTP protocol... just to name one... require that a client wait until the server has sent out an initial greeting banner before the client sends anything to the server. Some SMTP servers are lenient about enforcing this protocol rule, so in practice it may often not be necessary to wait for the greeting banner before sending SMTP commands from the client to the server. However there may perhaps be other instances where waiting actually is required, and thus I believe that an option to produce that kind of behavior might be a useful addition to the nc command. Regards, rfg From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 21 04:13:40 2013 Return-Path: Delivered-To: freebsd-hackers@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 2F503E7D for ; Sun, 21 Jul 2013 04:13:40 +0000 (UTC) (envelope-from n7w@delta.emu.st) Received: from smtp1.bushwire.net (f5.bushwire.net [199.48.133.46]) by mx1.freebsd.org (Postfix) with SMTP id D613E162 for ; Sun, 21 Jul 2013 04:13:38 +0000 (UTC) Received: (qmail 2129 invoked by uid 1001); 21 Jul 2013 04:13:38 -0000 Delivered-To: qmda-intercept-freebsd-hackers@freebsd.org DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=s384; d=delta.emu.st; b=k2VMzWegp4iV+q4/Al7OWqMdPrgIQLeda7PozB2rUrrUIP5L9DMIbkODQjNNajnq; Comments: DomainKeys? See http://en.wikipedia.org/wiki/DomainKeys DomainKey-Trace-MD: h=13; b=20; l=C18R70D32M64F38T31S69R80?45M17C39C27I57; Comments: QMDA 0.3 Received: (qmail 2122 invoked by uid 1001); 21 Jul 2013 04:13:38 -0000 Date: 21 Jul 2013 04:13:38 +0000 Message-ID: <20130721041338.2121.qmail@f5-external.bushwire.net> From: "Mark Delany" To: freebsd-hackers@freebsd.org Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon References: <24574.1374375946@server1.tristatelogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <24574.1374375946@server1.tristatelogic.com> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 04:13:40 -0000 > servers running certain protocols. For example, the rules of the SMTP > protocol... just to name one... require that a client wait until the > server has sent out an initial greeting banner before the client sends > anything to the server. Some SMTP servers are lenient about enforcing > this protocol rule, so in practice it may often not be necessary to wait A while back "fast talkers" as they were called, were a known signature of some spam bots. The guess is that they would just write the whole SMTP transaction in one write() immediately following the connect() and be done with it. A useful optimization when you're blatting out billions of spam. You don't see a big mention of this in search engines, so I don't know how prevalent they are now. Point being that such an option might be useful to avoid triggering any detectors that might still be looking for this. Mark. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 21 06:34:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D49A7246 for ; Sun, 21 Jul 2013 06:34:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 72AC762F for ; Sun, 21 Jul 2013 06:34:23 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id m19so4966625wev.22 for ; Sat, 20 Jul 2013 23:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DqNBcQMVkg2T/Dyhe8z7Pb3ySvukkwo/D3gNkPTgO7A=; b=KAhnPGywS2WAtRGsbLInmLlDaKIheaphr6qxuHnFhvvWL6whZ2iVeD0YKPkBMgeqSf BYty/sFMtLkLEEEbreTmXcHVCmwOSczQ2QE7UVKkJeIFyEdMRRdzlzly1zfcv+gHBF8j ayOK9e0tHQkS+awNiI2VtqdcrAx/hIMYAS4eusRrz1grFTDz+gnYmr/h5izokY60Nk0Z 8Wpl7XzgRu/BV1rB+K3BbjWKfIRiRzvas1Ft2Gww90yTaDXCejvhsPtdJmmi92cquCk4 S0pHZL9FWPOmxvmfyXpNjGnyyaVlLglIIF3/oZe/LegYpGnN0/Y+emXxbsxQU3QqpgE7 gGVA== MIME-Version: 1.0 X-Received: by 10.180.185.148 with SMTP id fc20mr15475379wic.0.1374388462589; Sat, 20 Jul 2013 23:34:22 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Sat, 20 Jul 2013 23:34:22 -0700 (PDT) In-Reply-To: <9921.1374330712@server1.tristatelogic.com> References: <9921.1374330712@server1.tristatelogic.com> Date: Sat, 20 Jul 2013 23:34:22 -0700 X-Google-Sender-Auth: _uKAyGxm-tn2kTet9O3ZQb0RBok Message-ID: Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon From: Adrian Chadd To: "Ronald F. Guilmette" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 06:34:23 -0000 Wait a second. What's going on under the hood? You _should_ be able to shutdown the write side of the socket and have it not affect reading. It's a broken server if it does a read(), find that the socket is returning EOF, and then not waiting for the write() to fail before closing. If that's actually what's going on - if you can verify that indeed its not some local broken handling of shutdown(fd, WR) then yes, I think it's worth changing nc. And I do think it's worth adding a "call shutdown(fd, WR) once the sender is finished" option for people that want it. -adrian On 20 July 2013 07:31, Ronald F. Guilmette wrote: > > > Could someone please take a look at this bug report (bin/176713) and > also at the simple patch that I provided to fix the problem? > > This is quite a serious problem, and my PR has been pending with no > action since Wed, 6 Mar 2013. > > > Regards, > rfg > > > P.S. Please note that in reality, I do not believe that it is necessary > to add a new -q option in order to preserve backwards compatability, however > I proposed one because in my experience there is always going to be some > purist who will claim that *any* change in semantics, however small or > helpful, in *any* software ``may'' break something. In reality, the > problem in this can most easily be solved simply by removing the one > statement: > > shutdown(nfd, SHUT_WR); > > entirely from the source, rather than making it conditional on -q, as I > suggested in my PR, bin/176713. > > P.P.S. I have just realized that yet one more critical enhancement for > nc is called for, and I will be filing a separate and additional PR for > that soon. I hope that someone will be able to take a look at that as > soon as it is filed. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 21 09:49:46 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CDAC38E1 for ; Sun, 21 Jul 2013 09:49:46 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by mx1.freebsd.org (Postfix) with ESMTP id 65416F10 for ; Sun, 21 Jul 2013 09:49:46 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id c10so1762926wiw.2 for ; Sun, 21 Jul 2013 02:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F3WNe18gIgcoNihh+nLFzNoXFhsjKQ5ePkm7ao9Jr2M=; b=B40XSRMN2dJHDJngqGrhkx7CIyBv17pXGebuBIJ3wYPyFERN7UA0VAM3EgM13ttqVq 6Esqe2OHBezIaAHDF6QLsb63zLePGmOXNsSsKrvpqi7TGcuD4MmZVM/WMDKO05qICUa3 xn4HrXG/2QlmKFSfyrJzjYrbnkBNOGcqMu7WJ/8XD3uLIdq5Gk2CIJkTaeE7vqyy9/dd yB8y1CkHz92u7Z+/A4jBrOHindgL59Xi0OpFj+WhJZ1tO+9Uxn4w8RScPltuaORME9X9 rzGiryCk7RkRhwgfGv7jhIHAUmyobAPB3Fvd+N8ZUnrmUGM4s4Es5V6TXAFbDGoEkRLN KjDA== MIME-Version: 1.0 X-Received: by 10.194.239.225 with SMTP id vv1mr16393341wjc.63.1374400184899; Sun, 21 Jul 2013 02:49:44 -0700 (PDT) Received: by 10.180.187.162 with HTTP; Sun, 21 Jul 2013 02:49:44 -0700 (PDT) In-Reply-To: <24574.1374375946@server1.tristatelogic.com> References: <24574.1374375946@server1.tristatelogic.com> Date: Sun, 21 Jul 2013 11:49:44 +0200 Message-ID: Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= To: "Ronald F. Guilmette" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 09:49:46 -0000 On Sun, Jul 21, 2013 at 5:05 AM, Ronald F. Guilmette wrote: > > In message Z1A3PgBtChAEhMbqB5fwPx-7emGbTSJ7AyMPA@mail.gmail.com> > =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= > wrote: > > >It seems to work for me: > > Good. > > Just to make sure that we are clear, you are simply confirming what my > bug report (bin/176713) said, i.e. that _without_ my fix, nc can > prematurely > truncate the output from some servers, whereas _with_ my fix this bad > behaviour on the part of nc is cured... Is that correct? > Yes, that is what I tested. Behavior before (truncated output) and after (correct output) applying the patch. If this is going to be the final version of the patch, i.e. if it is going to include the -q flag, then the patch needs to be extended to reflect that in nc(1) man page. > > If so, thank you for confirming that my proposed fix produces the > desired result. > > I feel compelled to say again that in actual point of fact, the way that > I personally would prefer to see this problem resolved would *not* be to > add a new option for the nc program. Rather, I think that it would > actually be best simply to delete from the nc source code the one single > line that is causing nc to stop its operation as soon as it receives > an EOF from its stdin channel. If that line is simply deleted, then > nc will instead wait until it receives an EOF from the remote server > that it is talking to, and quite obviously, this change causes nc to > produce output which is arguably more correct and which is certainly > more useful that the prematurely truncated results that nc sometimes > produces at present. > > >> P.P.S. I have just realized that yet one more critical enhancement for > >> nc is called for, and I will be filing a separate and additional PR for > >> that soon. I hope that someone will be able to take a look at that as > >> soon as it is filed. > > > >Just out of curiosity. What is it about? > > Well, as it turns out, the additional "fix" that I had believed that I > was going to propose for nc was not that critical after all... at least > not for my current and immediate application(s). However it might still > have some value in some cases anyway, so I will describe what I had in > mind. > > Quite simply, I believe that it would be Good if the nc program had a > new and additional option which, when used, would cause nc to refrain > from sending any data _to_ the remote server until such time as it had > received one entire line _from_ the remote server. > > Such an option could be useful when using nc to communicate with remote > servers running certain protocols. For example, the rules of the SMTP > protocol... just to name one... require that a client wait until the > server has sent out an initial greeting banner before the client sends > anything to the server. Some SMTP servers are lenient about enforcing > this protocol rule, so in practice it may often not be necessary to wait > for the greeting banner before sending SMTP commands from the client to > the server. However there may perhaps be other instances where waiting > actually is required, and thus I believe that an option to produce that > kind of behavior might be a useful addition to the nc command. > > > Regards, > rfg > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 22 01:44:15 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 67E729EC for ; Mon, 22 Jul 2013 01:44:15 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 491351C20 for ; Mon, 22 Jul 2013 01:44:14 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id EA60E3B604 for ; Sun, 21 Jul 2013 18:44:05 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-hackers@freebsd.org Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon In-Reply-To: <20130721041338.2121.qmail@f5-external.bushwire.net> Date: Sun, 21 Jul 2013 18:44:05 -0700 Message-ID: <91904.1374457445@server1.tristatelogic.com> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 01:44:15 -0000 In message <20130721041338.2121.qmail@f5-external.bushwire.net>, "Mark Delany" wrote: >> servers running certain protocols. For example, the rules of the SMTP >> protocol... just to name one... require that a client wait until the >> server has sent out an initial greeting banner before the client sends >> anything to the server. Some SMTP servers are lenient about enforcing >> this protocol rule, so in practice it may often not be necessary to wait > >A while back "fast talkers" as they were called, were a known >signature of some spam bots. That is correct. >The guess is that they would just write >the whole SMTP transaction in one write() immediately following the >connect() and be done with it. Yes. >A useful optimization when you're >blatting out billions of spam. I suppose so. >You don't see a big mention of this in search engines, so I don't know >how prevalent they are now. > >Point being that such an option might be useful to avoid triggering >any detectors that might still be looking for this. I'm sorry, but I am not following you. Were you attempting to say that this would be a good thing or a bad thing? (Personally, don't think it matters much one way or the other. Blocking "fast talkers" was never a terribly effective anti-spam technique. It was just "security through protocol pendantry", and was/is quite entirely trivial for the spammers to work around.) Regards, rfg From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 22 02:02:27 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A80D6C84 for ; Mon, 22 Jul 2013 02:02:27 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 870441C91 for ; Mon, 22 Jul 2013 02:02:27 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id C7C823B7FD for ; Sun, 21 Jul 2013 19:02:26 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-hackers@freebsd.org Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon In-Reply-To: Date: Sun, 21 Jul 2013 19:02:26 -0700 Message-ID: <91998.1374458546@server1.tristatelogic.com> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 02:02:27 -0000 In message Adrian Chadd wrote: >Wait a second. What's going on under the hood? > >You _should_ be able to shutdown the write side of the socket and have >it not affect reading. It has been some time now since I filed my PR but I think that the bottom line is that you need to look at the code (of nc) to understand how it is reacting to EOF on stdin. My recollection is that it exits as soon as it sees that (i.e. EOF on its own stdin). My proposed patch corrects this unfortunate behavior. >It's a broken server if it does a read(), find >that the socket is returning EOF, and then not waiting for the write() >to fail before closing. The server(s) is/are not at fault in this instance. It is the *client*, i.e. nc, which is broken in its behavior. With respect to that, I *do* 100% agree with you that nc's current behavior is absolutely and unambiguously broken. What nc is currently doing is goofy and also provably counterproductive for most applications where one can envision nc being used, i.e. specifically in *non-interactive* scripting applications. In all such applications of nc it is essentially 100% likely that the input stream which will be given to nc will be coming from either (a) some disk file or else (b), more likely via a pipe from some other commands/scripts/programs. In all such cases, nc is likely to see the EOF on its stdin well before the remote server is finished sending down its reply, and thus, as has been demonstrated, nc will incorrectly truncate the server's reply. Note also that if you accept my premise, i.e. that nc is used, and that it will be used always (or virtually always) within non-interactive scenarios/contexts... leaving telnet for people who need a more inter- actively oriented tool... then there really is no need to accompany the change I have propsed with a new "-q" option, and instead the current behavior of nc can simply be changed from "exit-on-stdin-EOF" to "exit-on-remote-server-EOF", with no further or additional code changes. Regards, rfg From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 22 02:10:16 2013 Return-Path: Delivered-To: freebsd-hackers@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 C005FEDF for ; Mon, 22 Jul 2013 02:10:16 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id A181B1CC2 for ; Mon, 22 Jul 2013 02:10:16 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 11B233B604 for ; Sun, 21 Jul 2013 19:10:16 -0700 (PDT) From: "Ronald F. Guilmette" To: FreeBSD Hackers Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon In-Reply-To: Date: Sun, 21 Jul 2013 19:10:16 -0700 Message-ID: <92036.1374459016@server1.tristatelogic.com> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 02:10:16 -0000 In message =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= wrote: >Yes, that is what I tested. Behavior before (truncated output) and after >(correct output) applying the patch. OK, good. Thanks. >If this is going to be the final version of the patch, i.e. if it is going >to include the -q flag, then the patch needs to be extended to reflect that >in nc(1) man page. I am in complete agreement that _if_ a new option is implemented within nc then it really must also be properly documented in the associated man page. As I have expressed however, it is my hope that whoever decides these things will decide to simply fix the bug in nc and to _not_ even bother to introduce an option which might help to preserve ``backward compatability'' with the current (broken) behavior of nc. I simply do not believe that the current (arguably "broken") behavior of nc is of any particular value to anybody. The only reason I proposed a patch that included an option to elicit the (non-broken) behavior was because I have the humility to admit that I am not actually omniscient with respect to other people's needs. Regards, rfg From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 22 02:50:49 2013 Return-Path: Delivered-To: freebsd-hackers@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 08DBF719 for ; Mon, 22 Jul 2013 02:50:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 004481DA6 for ; Mon, 22 Jul 2013 02:50:47 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id e11so5384752wgh.18 for ; Sun, 21 Jul 2013 19:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=afcA05fwEPMmKSm9rtCwRiDWgSbQRqnlU7SZiaq96cA=; b=Y0qkQF7jMm3u5hifvZ0KsEQCxo3oYrAZCTWJTDFVwYp5bZt5ed4JIFkoPP3BxUscpH kJzC3NLOxQ4TxPTLhbYqluiqh4zyV73ONcT1n/qsDgLTw+iyG09rYPc2VSRN+1iMFImY bq2ssEZfvRW4EMA/ylMbtmNsTofPzJ4W9lIR+xip1DC+f0ZoUyO8nJMXrCvQ0Jsa/rCk s+Z5sktEnqCv5BgA51HqA9lTitBOJmDPOusfyD7qdhJ3kVcJDVg7bGw1AqTZNRKHewlP s0fpAt8n+G2bKOrDsPYZ4QIgButc3uQTz64353w5fOH7VoJYRh9DRhZW59TMSokflmrS bUuA== MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr17614281wjs.79.1374461446377; Sun, 21 Jul 2013 19:50:46 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Sun, 21 Jul 2013 19:50:46 -0700 (PDT) In-Reply-To: <91998.1374458546@server1.tristatelogic.com> References: <91998.1374458546@server1.tristatelogic.com> Date: Sun, 21 Jul 2013 19:50:46 -0700 X-Google-Sender-Auth: RDiArvYtdbJ8ceMYNJum-uatgjA Message-ID: Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon From: Adrian Chadd To: "Ronald F. Guilmette" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 02:50:49 -0000 On 21 July 2013 19:02, Ronald F. Guilmette wrote: > It has been some time now since I filed my PR but I think that the bottom > line is that you need to look at the code (of nc) to understand how it is > reacting to EOF on stdin. Gah, I was kinda hoping not to look at nc, and just work with someone else to figure out the right solution. I'm being slack :) > My recollection is that it exits as soon as it sees that (i.e. EOF on > its own stdin). My proposed patch corrects this unfortunate behavior. OK. Let me re-read this. I _think_ the correct behaviour is: * if it's done a shutdown(fd, WR) - then it shouldn't error out on EOF events on writes to the FD * But it shouldn't get a read EOF on the socket until the remote side signifies it. Is nc seeing EOF on reading form the server side prematurely? That's why I'm confused. -adrian From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 22 03:06:23 2013 Return-Path: Delivered-To: freebsd-hackers@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 C09D324D for ; Mon, 22 Jul 2013 03:06:23 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id A17C21F1A for ; Mon, 22 Jul 2013 03:06:23 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 5E7F33B604 for ; Sun, 21 Jul 2013 20:06:20 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-hackers@freebsd.org Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon In-Reply-To: Date: Sun, 21 Jul 2013 20:06:20 -0700 Message-ID: <94798.1374462380@server1.tristatelogic.com> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 03:06:23 -0000 In message Adrian Chadd wrote: > On 21 July 2013 19:02, Ronald F. Guilmette wrote: > >> It has been some time now since I filed my PR but I think that the bottom >> line is that you need to look at the code (of nc) to understand how it is >> reacting to EOF on stdin. > >Gah, I was kinda hoping not to look at nc, and just work with someone >else to figure out the right solution. I'm being slack :) I did not know that was allowed on the freebsd-hackers list. :-) >> My recollection is that it exits as soon as it sees that (i.e. EOF on >> its own stdin). My proposed patch corrects this unfortunate behavior. > >OK. Let me re-read this. I _think_ the correct behaviour is: > >* if it's done a shutdown(fd, WR) - then it shouldn't error out on EOF >events on writes to the FD What? I don't understand what you just said. >* But it shouldn't get a read EOF on the socket until the remote side >signifies it. It isn't just that it "shouldn't". It most certainly DOES NOT receive an EOF from the remote server until such time as the remote server does in fact close down its side of the connection. >Is nc seeing EOF on reading form the server side prematurely? No. It is not. Prior to receiving the final portion of the response from the remote server and prior also to the remote server closing its end of the connection (i.e. ``sending an EOF'') the nc program see an EOF on its stdin channel and it decides, based on that alone, that it should exit immediately without waiting _either_ for further data coming down from the remote server _or_ for the actual and final EOF from the remote server. The result is that nc has a tendency to truncate the response data that is coming back from the remote server, only printing just the (incomplete) first part of it, rather than all of it, as it arguably should be doing. I hope that helps. Regards, rfg From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 22 07:28:06 2013 Return-Path: Delivered-To: freebsd-hackers@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 CA3B09B0 for ; Mon, 22 Jul 2013 07:28:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 654C92659 for ; Mon, 22 Jul 2013 07:28:06 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id q57so2209498wes.21 for ; Mon, 22 Jul 2013 00:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ihbIJFIMquOk5/ILHRRwZ8jyjmuU5dQN4pUY9+B4F3M=; b=Fedae18RLXIic96bDTppduCYXUhr/RT47cV2Varu7OE7+g36aMGaYhPWS2kA5oFQnl xIo44sf8Rf1/Zk5vFxRWy0902/A5o75fN5k2+M+Oh8AcOcHz4lNYgbpRFP1JmwVDdHbc MPFAdjWpXK/hvxQmN8m2S8vDCIYX4KRvGL6L+zWHHLdTp80kVF+JV0WxcsRnLoMAL4te vVMKKowdqlFYH12VToeTdD4DzIl9j0pffrBry8jUhQGMD7WsseFTjFkEkslMlUG7pSFb zpOVnNq6HFhjO2YBYsJVXBvW6nBDpHWxFsfb66jn8sPbR3DIBwdhIBwtxWRkdIVm6uds uWmQ== MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr18146115wjs.79.1374478084717; Mon, 22 Jul 2013 00:28:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Mon, 22 Jul 2013 00:28:04 -0700 (PDT) In-Reply-To: <94798.1374462380@server1.tristatelogic.com> References: <94798.1374462380@server1.tristatelogic.com> Date: Mon, 22 Jul 2013 00:28:04 -0700 X-Google-Sender-Auth: NspVAktLy2RD8njSduNhI2F-11k Message-ID: Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon From: Adrian Chadd To: "Ronald F. Guilmette" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 07:28:06 -0000 Right. Yes, I had a typo. I meant that it shouldn't die on seeing a read EOF after closing the write side of the socket. So, what you're saying is: * nc sees EOF on stdin * nc decides to abort before seeing the rest of the data come in from the remote socket (and then trying to write it, and aborting if it sees EOF on stdin _and_ EOF/error on writing to stdout) Right? -adrian From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 22 17:45:49 2013 Return-Path: Delivered-To: freebsd-hackers@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 2D7F573; Mon, 22 Jul 2013 17:45:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A18652AD1; Mon, 22 Jul 2013 17:45:48 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C7B15B948; Mon, 22 Jul 2013 13:45:46 -0400 (EDT) From: John Baldwin To: Yuri Subject: Re: Kernel crashes after sleep: how to debug? Date: Mon, 22 Jul 2013 12:17:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <51E3A334.8020203@rawbw.com> <201307191704.47622.jhb@freebsd.org> <51E9F2EF.6000908@rawbw.com> In-Reply-To: <51E9F2EF.6000908@rawbw.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201307221217.03525.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 22 Jul 2013 13:45:46 -0400 (EDT) Cc: Alan Cox , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:45:49 -0000 On Friday, July 19, 2013 10:16:15 pm Yuri wrote: > On 07/19/2013 14:04, John Baldwin wrote: > > Hmm, that definitely looks like garbage. How are you with gdb scriptin= g? > > You could write a script that walks the PQ_ACTIVE queue and see if this > > pointers ends up in there. It would then be interesting to see if the > > previous page's next pointer is corrupted, or if the pageq.tqe_prev ref= erences > > that page then it could be that this vm_page structure has been stomped= on > > instead. >=20 > As you suggested, I printed the list of pages. Actually, iteration in=20 > frame 8 goes through PQ_INACTIVE pages. So I printed those. > <...skipped...> > ### page#2245 ### > $4492 =3D (struct vm_page *) 0xfffffe00b5a27658 > $4493 =3D {pageq =3D {tqe_next =3D 0xfffffe00b5a124d8, tqe_prev =3D=20 > 0xfffffe00b5b79038}, listq =3D {tqe_next =3D 0x0, tqe_prev =3D=20 > 0xfffffe00b5a276e0}, > left =3D 0x0, right =3D 0x0, object =3D 0xfffffe005e3f7658, pindex =3D= 5,=20 > phys_addr =3D 1884901376, md =3D {pv_list =3D {tqh_first =3D 0xfffffe005e= 439ce8, > tqh_last =3D 0xfffffe00795eacc0}, pat_mode =3D 6}, queue =3D 0 '\0= ',=20 > segind =3D 2 '\002', hold_count =3D 0, order =3D 13 '\r', pool =3D 0 '\0', > cow =3D 0, wire_count =3D 0, aflags =3D 1 '\001', flags =3D 64 '@', of= lags =3D=20 > 0, act_count =3D 9 '\t', busy =3D 0 '\0', valid =3D 255 '=EF=BF=BD', dirt= y =3D 255 '=EF=BF=BD'} > ### page#2246 ### > $4494 =3D (struct vm_page *) 0xfffffe00b5a124d8 > $4495 =3D {pageq =3D {tqe_next =3D 0xfffffe00b460abf8, tqe_prev =3D=20 > 0xfffffe00b5a27658}, listq =3D {tqe_next =3D 0x0, tqe_prev =3D=20 > 0xfffffe005e3f7cf8}, > left =3D 0x0, right =3D 0x0, object =3D 0xfffffe005e3f7cb0, pindex =3D= 1,=20 > phys_addr =3D 1881952256, md =3D {pv_list =3D {tqh_first =3D 0xfffffe005e= 42dd48, > tqh_last =3D 0xfffffe007adb03a8}, pat_mode =3D 6}, queue =3D 0 '\0= ',=20 > segind =3D 2 '\002', hold_count =3D 0, order =3D 13 '\r', pool =3D 0 '\0', > cow =3D 0, wire_count =3D 0, aflags =3D 1 '\001', flags =3D 64 '@', of= lags =3D=20 > 0, act_count =3D 9 '\t', busy =3D 0 '\0', valid =3D 255 '=EF=BF=BD', dirt= y =3D 255 '=EF=BF=BD'} > ### page#2247 ### > $4496 =3D (struct vm_page *) 0xfffffe00b460abf8 > $4497 =3D {pageq =3D {tqe_next =3D 0xfe26, tqe_prev =3D 0xfffffe00b5a124d= 8},=20 > listq =3D {tqe_next =3D 0xfffffe0081ad8f70, tqe_prev =3D 0xfffffe0081ad8f= 78}, > left =3D 0x6, right =3D 0xd00000201, object =3D 0x100000000, pindex = =3D=20 > 4294901765, phys_addr =3D 18446741877712530608, md =3D {pv_list =3D { > tqh_first =3D 0xfffffe00b460abc0, tqh_last =3D 0xfffffe00b5579020}= ,=20 > pat_mode =3D -1268733096}, queue =3D 72 'H', segind =3D -85 '=EF=BF=BD', > hold_count =3D -19360, order =3D 0 '\0', pool =3D 254 '=EF=BF=BD', cow= =3D 65535,=20 > wire_count =3D 0, aflags =3D 0 '\0', flags =3D 0 '\0', oflags =3D 0, > act_count =3D 0 '\0', busy =3D 176 '=EF=BF=BD', valid =3D 208 '=EF=BF= =BD', dirty =3D 126 '~'} > ### page#2248 ### > $4498 =3D (struct vm_page *) 0xfe26 >=20 > The page #2247 is the same that caused the problem in frame 8. tqe_next=20 > is apparently invalid, so iteration stopped here. > It appears that this structure has been stomped on. This page is=20 > probably supposed to be a valid inactive page. Yes, it's phys_addr is also way off. I think you might even be able to figure out which phys_addr it is supposed to have based on the virtual address (see PHYS_TO_VM_PAGE() in vm/vm_page.c) by using the vm_page address and phys_addr of the prior entries to establish the relative offset. It is certainly a page "earlier" in the array. > > Ultimately I think you will need to look at any malloc/VM/page operatio= ns > > done in the suspend and resume paths to see where this happens. It mig= ht > > be slightly easier if the same page gets trashed every time as you could > > print out the relevant field periodically during suspend and resume to > > narrow down where the breakage occurs. >=20 > I am thinking to put code walking through all page queues and verifying=20 > that they are not damaged in this way into the code when each device is=20 > waking up from sleep. > dev/acpica/acpi.c has acpi_EnterSleepState, which, as I understand,=20 > contains top-level code for S3 sleep. Before sleep it invokes event=20 > 'power_suspend' on all devices, and after sleep it calls 'power_resume'=20 > on devices. So maybe I will call the page check procedure after=20 > 'power_suspend' and 'power_resume'. >=20 > But it is possible that memory gets damaged somewhere else after=20 > power_resume happens. > Do you have any thought/suggestions? Well, I think you should try what you've suggeseted above first. If that doesn't narrow it down then we can brainstorm some other places to inspect. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 22 17:45:49 2013 Return-Path: Delivered-To: hackers@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 923F975; Mon, 22 Jul 2013 17:45:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 629722AD2; Mon, 22 Jul 2013 17:45:49 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D4FD5B94C; Mon, 22 Jul 2013 13:45:47 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: UFS related panic (daily <-> find) Date: Mon, 22 Jul 2013 13:29:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130719.174511.786.3@DOMY-PC> In-Reply-To: <20130719.174511.786.3@DOMY-PC> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1250" Content-Transfer-Encoding: 7bit Message-Id: <201307221329.47690.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 22 Jul 2013 13:45:47 -0400 (EDT) Cc: rank1seeker@gmail.com, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:45:49 -0000 On Friday, July 19, 2013 1:45:11 pm rank1seeker@gmail.com wrote: > I had 2 panics: (Both occured at 3 AM, so had to be daily task) > > First (Jul 2 03:06:50 2013): > -- > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x19 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06caf34 > stack pointer = 0x28:0xe76248fc > frame pointer = 0x28:0xe7624930 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 76562 (find) > trap number = 12 > panic: page fault > Uptime: 23h0m41s > Physical memory: 1014 MB > Dumping 186 MB: 171 155 139 123 107 91 75 59 43 27 11 > > #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990, vpp=0xe7624ae8, > cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at /usr/src/sys/kern/vfs_cache.c:547 Can you go up to this frame and do 'l'? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 22 18:12:31 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A8C4DF8 for ; Mon, 22 Jul 2013 18:12:31 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 8E9382CA2 for ; Mon, 22 Jul 2013 18:12:31 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 0FB5A3ACEA for ; Mon, 22 Jul 2013 11:12:28 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-hackers@freebsd.org Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon In-Reply-To: Date: Mon, 22 Jul 2013 11:12:28 -0700 Message-ID: <99748.1374516748@server1.tristatelogic.com> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 18:12:31 -0000 In message Adrian Chadd wrote: >Right. Yes, I had a typo. I meant that it shouldn't die on seeing a >read EOF after closing the write side of the socket. > >So, what you're saying is: > >* nc sees EOF on stdin Yes. >* nc decides to abort before seeing the rest of the data come in from >the remote socket Yes. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 23 02:28:25 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A57835C2 for ; Tue, 23 Jul 2013 02:28:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 407832004 for ; Tue, 23 Jul 2013 02:28:25 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id m15so1251416wgh.5 for ; Mon, 22 Jul 2013 19:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WMlglG7QoB9vVljRDcmvzjfWDqWRLz2E2MwY3rWHmxY=; b=DDxJkin6CyRP3uA2oAV2GA77pGLfdsPoBEL8/pnTTU7MpCZTocNx/b2WFCO72aLj/1 go2iGi/bkOiWI4oA2kTRwKNYGMgRpPF6nzNVT0hNQnJPMY7PF4aneYFOgHqB7nXSLzub P3VDfT+eytNBjXhOnI9o3AV8teeWi6emfhHmv5vfaq5UtfH/j1UockhIYK14r32Jvu9Z fJgm+VZFqMKANKbUGcybuGwbztrKSXfwjWrTa7RmorVifERj/6KFp0gtL4dNuJiGmhKa NWPldDz8Bb4ZFgLCCyonGUVynhDWgjufSQEYIxLZbimpTRatLVB/YKkm7pqCZMB+xGgM UcrQ== MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr20981556wjs.79.1374546503664; Mon, 22 Jul 2013 19:28:23 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Mon, 22 Jul 2013 19:28:23 -0700 (PDT) In-Reply-To: <99748.1374516748@server1.tristatelogic.com> References: <99748.1374516748@server1.tristatelogic.com> Date: Mon, 22 Jul 2013 19:28:23 -0700 X-Google-Sender-Auth: TdQVZ0FHs7Uj0n15RHySCFHMi-s Message-ID: Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon From: Adrian Chadd To: "Ronald F. Guilmette" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 02:28:25 -0000 Right, and your patch just stops the shutdown(), right? Rather than teaching nc to correctly check BOTH socket states before deciding to close things. I'd personally rather see nc taught to check to see whether it can possibly make ANY more progress before deciding to shut things down. -adrian From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 23 15:35:17 2013 Return-Path: Delivered-To: freebsd-hackers@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 26BC3D7F; Tue, 23 Jul 2013 15:35:17 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DCAC124D9; Tue, 23 Jul 2013 15:35:16 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id m1so1711855oag.34 for ; Tue, 23 Jul 2013 08:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Dl3ew/qWIkNssY/tnrsJaeZh+kDOYfA3U7CcUKW1AW8=; b=w6E07htIMtGlUHj1NASNTwHDIZbGYAMcoH66lHKhal8pFTVYUORZeQdFXRMPhldK0U Polwd/mkU7BF0tiRZ5rpkskOyrWjBVEW1j/tAF3vpSnbHYNG1N8vmUJHAZg7JVfZhipl X8NarbUpbdh8wOoIHAq9bZk1aRJ+Q0VTq/ZnS7xjvpeSGeo6rNbyuj5i7A/+EEigX/a5 3IEdIe4YJXxILf5Pj8BaJrVRJi9l9WnOger+Y71p1xZAIllx9JVA+bHIynhswSkTsqIS lxuF1jWGb5a/BHkWh1nZmCG9/Oto5/6/zyJOQUcNlGvKQ5emL3Mg37/natAIr1dZHim9 MFVw== X-Received: by 10.60.45.38 with SMTP id j6mr31218522oem.56.1374593716248; Tue, 23 Jul 2013 08:35:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.130.204 with HTTP; Tue, 23 Jul 2013 08:34:46 -0700 (PDT) In-Reply-To: References: <20110129084125.GA54969@freebsd.org> <20130108150155.GF82219@kib.kiev.ua> From: Jia-Shiun Li Date: Tue, 23 Jul 2013 23:34:46 +0800 Message-ID: Subject: Re: cpufreq not working as module on i386/amd64 To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, Andriy Gapon X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 15:35:17 -0000 On Thu, Jul 4, 2013 at 1:37 PM, Jia-Shiun Li wrote: > ok anyone can help test and review this patch? > > It will allow cpufreq to be removed from kernel conf, loaded and > function correctly as kernel module. I've tested it ok on my own > i5-3450. > > It removes get_features method definition from acpi_if.m and > corresponding implementations from est, p4tcc, & hwpstate. Feature > flags are set directly in acpi_cpu.c omitting previous procedure of > querying cpufreq drivers. > I submitted the patch as PR kern/180588. Could anyone help review and get this committed? Thanks, Jia-Shiun. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 23 19:49:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 04943A35; Tue, 23 Jul 2013 19:49:55 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BD06221B1; Tue, 23 Jul 2013 19:49:54 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id n12so7521275oag.22 for ; Tue, 23 Jul 2013 12:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=g8zjAyPN6O1GpCU/tADv0BnyV4Pzrawo3KVIX/kvx4o=; b=KqWy3SQcZ+W7yJdSOhPLMjbBgu0R62ccQsEeCBr5PWUHQ0/WjdlZcEK7KOLKFjURze 5IqjaZ3YgEUMXqdR7r/yQ+5zGK1TMBVluZcMjdHMq9sLwl/0EqAWkymjsyi14/iqeSMP IRVlpAlhqwugsaLBwNh2VcYB1HbVJqkoVXS9Cs/dWSqaww/Z1ICI0y6JWFbfUIQqXtmf OBJmQVh3o2cNdHTzMUq7qTj9uIh7GRdhVx1jUijSx5zLlXwHgAhzJ8J+UppXSgF0c4n2 pmyP3mmGNkL6cyiZZVmGWKVBZz7wxM5Gb7VqY3aaTCmNUrNH0jZ8aevcav05lbyy697k 20kA== MIME-Version: 1.0 X-Received: by 10.182.79.201 with SMTP id l9mr4051974obx.61.1374608993910; Tue, 23 Jul 2013 12:49:53 -0700 (PDT) Received: by 10.182.115.194 with HTTP; Tue, 23 Jul 2013 12:49:53 -0700 (PDT) Date: Tue, 23 Jul 2013 15:49:53 -0400 Message-ID: Subject: Increasing the kernel hertz rate in 10.0, RELEASE, and CURRENT From: Super Bisquit To: FreeBSD Hackers , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 19:49:55 -0000 At 2500 Hz, the tick rate increases by 1 Hz per cycle. There was mention of a patch that would allow the rate to be as high as 40k without this effect. --I'll post the link as soon as I find the mailing list thread-- Will this patch work with the current available releases? From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 23 23:17:10 2013 Return-Path: Delivered-To: hackers@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 52593D3F for ; Tue, 23 Jul 2013 23:17:10 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from www.rawbandwidth.com (www.rawbandwidth.com [198.144.193.1]) by mx1.freebsd.org (Postfix) with ESMTP id 374B92BEA for ; Tue, 23 Jul 2013 23:17:09 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by www.rawbandwidth.com (8.14.4/8.14.4) with ESMTP id r6NNH2YZ009238 for ; Tue, 23 Jul 2013 16:17:02 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <51EF0EEE.8030000@rawbw.com> Date: Tue, 23 Jul 2013 16:17:02 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Hackers Subject: Should process run under chroot(8) still see mounts on the original system? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 23:17:10 -0000 Currently, mount directories as shown by mount(8) command and /compat/linux/dev/mounts from linprocfs(5) still show the original mount points as other non-chrooted processes see. So, when some program run under chroot tries to read the mount points and do something with them it would likely fail because those paths aren't what the process actually sees in its file system. There are two situations: one when the process was started already chrooted (like with command chroot(8)), and another one is when process calls chroot(2) itself. Currently system seems to not differentiate between these two cases. It looks reasonable to automatically modify mount(8) and linprocfs(5) results when the process has been started already chrooted and this process is (practically) always unaware of chroot. So that when chroot was in place when execve(2), kernel could set the boolean flag and later adjust mount directories accordingly. I hit this issue while playing with GoogleTalk plugin (the linux app). I am running it in chroot environment, since it requires the higher linux libraries version than are currently installed on the host. It runs and connects to the browser plugin. But when it reads /compat/linux/dev/mounts in order to find /dev/shm (linux shm_open(3) function), it sees the wrong paths there and fails. It can't statfs the mount point. Yuri From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 23 23:31:11 2013 Return-Path: Delivered-To: hackers@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 A8FCEF82 for ; Tue, 23 Jul 2013 23:31:11 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 434BD2C64 for ; Tue, 23 Jul 2013 23:31:11 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ey16so3636137wid.16 for ; Tue, 23 Jul 2013 16:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=TqWLO8zuS0ouARqShQrHGyQXgONcI2IZd1FBNfhFKZ0=; b=Do5LFfChafy7xbo+5WQUDDR3fhySTRDrsGl945dl9yCDwSxcJPaZrBafNbIvXSIVr6 KU7QxORvEdycj4O/J+JIekWqsaBnXBOurFnQeLIvVQ9YVA2IykBXbfsh4po0+I+E65MY ebf52CgNYm1XTdkLhARmEffRWOKvTg8/B87+fLyt9n4lBaXEM9qDdmkYtefzbT0bfNbB 76Q34WaN4RUAHCgPZ1Ev5yHK+bHJkh7UQc6E1Fl2jpoutYuMmnmWL7Q1A8GELHfCfVFJ nRFnMf9GOocbF34hf4l5OlI+/FptQe3+vQfrACoA7x3gqacqTmf/YaUsNXk+JjoPrt5H 5aLg== X-Received: by 10.194.104.199 with SMTP id gg7mr25174696wjb.56.1374622269527; Tue, 23 Jul 2013 16:31:09 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id fd3sm1602927wic.10.2013.07.23.16.31.07 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 23 Jul 2013 16:31:08 -0700 (PDT) Date: Wed, 24 Jul 2013 01:31:02 +0200 From: Mateusz Guzik To: Yuri Subject: Re: Should process run under chroot(8) still see mounts on the original system? Message-ID: <20130723233102.GA19249@dft-labs.eu> References: <51EF0EEE.8030000@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <51EF0EEE.8030000@rawbw.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 23:31:11 -0000 On Tue, Jul 23, 2013 at 04:17:02PM -0700, Yuri wrote: > Currently, mount directories as shown by mount(8) command and > /compat/linux/dev/mounts from linprocfs(5) still show the original > mount points as other non-chrooted processes see. > So, when some program run under chroot tries to read the mount > points and do something with them it would likely fail because those > paths aren't what the process actually sees in its file system. > > There are two situations: one when the process was started already > chrooted (like with command chroot(8)), and another one is when > process calls chroot(2) itself. Currently system seems to not > differentiate between these two cases. > > It looks reasonable to automatically modify mount(8) and > linprocfs(5) results when the process has been started already > chrooted and this process is (practically) always unaware of chroot. > So that when chroot was in place when execve(2), kernel could set > the boolean flag and later adjust mount directories accordingly. > While changing the code to do what you propose would not be that difficult, I don't see the point. In cases like this you can simply jail(2) and there you go (or at least this should work just fine). Of course then you may have some unnecessary separation but that I believe can be simply worked out if it turns out to be problematic. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 23 23:44:19 2013 Return-Path: Delivered-To: hackers@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 D8B5638B for ; Tue, 23 Jul 2013 23:44:19 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from www.rawbandwidth.com (www.rawbandwidth.com [198.144.193.1]) by mx1.freebsd.org (Postfix) with ESMTP id 9FD7A2CDD for ; Tue, 23 Jul 2013 23:44:19 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by www.rawbandwidth.com (8.14.4/8.14.4) with ESMTP id r6NNiIgE015494; Tue, 23 Jul 2013 16:44:19 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <51EF1552.4050003@rawbw.com> Date: Tue, 23 Jul 2013 16:44:18 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mateusz Guzik Subject: Re: Should process run under chroot(8) still see mounts on the original system? References: <51EF0EEE.8030000@rawbw.com> <20130723233102.GA19249@dft-labs.eu> In-Reply-To: <20130723233102.GA19249@dft-labs.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 23:44:19 -0000 On 07/23/2013 16:31, Mateusz Guzik wrote: > Of course then you may have some unnecessary separation but that I > believe can be simply worked out if it turns out to be problematic. jail would completely separate two systems. In my case this app also communicates through files that it creates and host app reads through symbolic links. It might also be assuming that it runs on the same host and maybe is unable to connect to X server other than through the shared memory. Such functionality can be made optional through some sysctl variable. Yuri From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 23 23:44:52 2013 Return-Path: Delivered-To: hackers@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 D1E18478; Tue, 23 Jul 2013 23:44:52 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9ADCD2CEA; Tue, 23 Jul 2013 23:44:52 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id r6NNipK0003762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 23 Jul 2013 18:44:51 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.02.0309.002; Tue, 23 Jul 2013 18:44:50 -0500 From: "Teske, Devin" To: Mateusz Guzik Subject: Re: Should process run under chroot(8) still see mounts on the original system? Thread-Topic: Should process run under chroot(8) still see mounts on the original system? Thread-Index: AQHOh/rIXlLJowOYcE29FHu1Q8jZsplzPT8AgAAD2YA= Date: Tue, 23 Jul 2013 23:44:49 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FD74F9@ltcfiswmsgmb21> References: <51EF0EEE.8030000@rawbw.com> <20130723233102.GA19249@dft-labs.eu> In-Reply-To: <20130723233102.GA19249@dft-labs.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <2019042961626F489433D4609E0770F6@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-23_06:2013-07-22,2013-07-23,1970-01-01 signatures=0 Cc: Devin Teske , Yuri , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 23:44:53 -0000 On Jul 23, 2013, at 4:31 PM, Mateusz Guzik wrote: > On Tue, Jul 23, 2013 at 04:17:02PM -0700, Yuri wrote: >> Currently, mount directories as shown by mount(8) command and >> /compat/linux/dev/mounts from linprocfs(5) still show the original >> mount points as other non-chrooted processes see. >> So, when some program run under chroot tries to read the mount >> points and do something with them it would likely fail because those >> paths aren't what the process actually sees in its file system. >>=20 >> There are two situations: one when the process was started already >> chrooted (like with command chroot(8)), and another one is when >> process calls chroot(2) itself. Currently system seems to not >> differentiate between these two cases. >>=20 >> It looks reasonable to automatically modify mount(8) and >> linprocfs(5) results when the process has been started already >> chrooted and this process is (practically) always unaware of chroot. >> So that when chroot was in place when execve(2), kernel could set >> the boolean flag and later adjust mount directories accordingly. >>=20 >=20 > While changing the code to do what you propose would not be that > difficult, I don't see the point. In cases like this you can simply > jail(2) and there you go (or at least this should work just fine). >=20 > Of course then you may have some unnecessary separation but that I > believe can be simply worked out if it turns out to be problematic. >=20 What the OP wants is implemented for jails via the sysctl ``knob'' "securit= y.jail.enforce_statfs" It can have one of three values. 0 =3D show nothing from the base in jailed df(1) output 2 =3D show everything from the base in jailed df(1) output What you want sounds like the number in-between: 1 =3D show only mount points from the base that appear within the jail *and= * make the jailed df(1) output show a modified path that is rooted in said = jail --=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-hackers@FreeBSD.ORG Tue Jul 23 23:48:41 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B78DA8F4 for ; Tue, 23 Jul 2013 23:48:41 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 9662E2D24 for ; Tue, 23 Jul 2013 23:48:41 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 3DFEC3B615 for ; Tue, 23 Jul 2013 16:48:33 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-hackers@freebsd.org Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon In-Reply-To: Date: Tue, 23 Jul 2013 16:48:33 -0700 Message-ID: <11109.1374623313@server1.tristatelogic.com> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 23:48:41 -0000 In message Adrian Chadd wrote: >Right, and your patch just stops the shutdown(), right? The shutdown that occurs when EOF is encountered on stdin, yes. >Rather than >teaching nc to correctly check BOTH socket states before deciding to >close things. In effect, nc *is* currently "checking both sockets" and that is exactly the problem. It terminates (prematurely in some cases) whenever it sees an EOF _either_ from the remote host _or_ from stdin. My patch casuses nc to wait for EOF from the remote server before exiting, EVEN IF prior to the time it sees that EOF from the remote server it sees an EOF (first) on stdin. This code change demonstratably makes the functionality of nc better and more pragmatically useful in typical use cases. You appear to be proposing something else, but I'm sorry to say that I cannot decypher what, exactly you are attempting to propose. I have proposed specific code changes. If you have some different ones that you would like to propose, then I feel sure that everyone on the hackers list, including myself, would be interested to take a look at what you have in mind, and also what problem you are solving. >I'd personally rather see nc taught to check to see whether it can >possibly make ANY more progress before deciding to shut things down. I believe that that is exactly what the patch that I proposed does. I'm not sure why you feel otherwise. Look, there are only two scenarios... either (a) EOF arrives from stdin first or else (b) EOF arrives from the remote server first. My patch causes nc to continue gathering data from the remote server (and copying it all to stdout) in case (a). In case (b) there is no point in nc continuing to run (and/or continuing to read from stdin) if the remote server has shut down the connection. In this case, the data that nc might yet gather from its stdin channel has noplace to go! So whenever nc has sensed an EOF from the remote server it can (and should) immediately shut down... and that is exactly what it is _already_ programmed to do. So, what problem do you want to solve that is not solved by the patch that I already proposed? Also, with respect, if you think there really is some other problem, then proposing actual concrete patches to solve that other problem would perhaps allow folks, including myself, to better understand what it is that you are driving at. Regards, rfg From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 24 00:19:10 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 94D19F0 for ; Wed, 24 Jul 2013 00:19:10 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2C8F72E6E for ; Wed, 24 Jul 2013 00:19:10 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id j13so2352202wgh.3 for ; Tue, 23 Jul 2013 17:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=R006wjweS+okH1ocpPMz4qaRqaRtMxtekXDhbyQJY5Y=; b=xrSyaC8j1WH6iEqtL3X65sQ59kmIxw7q5IKYJyydZLb9UuP4Ek1shJebq6iOrf6hOe IBoYXTCKOhi10WYUMlBaOC6HqegWxppzltfhinQYhTEiytr6mieRUE7tCtXuqn9/m5WO dyOerx4lLgey9yTekJtytRp9+yZYvbj3s0a1SujR5KFcGZrtpgVqf0Y9isXC6LuK9IpU XVLUBgTLqcGs257/OAUlFJqEWsbVxkqAOzO/bWNEfClVkLf7jp6FHnDZJV6XdMgnxQiS TWTEWRyV3syMKvBTl1UIuJRyomShPhxc8NWyOuAMR9d9yONkQ2HQiDOMYrjHPUkZvflb UzZg== X-Received: by 10.194.63.46 with SMTP id d14mr25319413wjs.81.1374625148574; Tue, 23 Jul 2013 17:19:08 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id x2sm1805527wif.3.2013.07.23.17.19.06 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 23 Jul 2013 17:19:07 -0700 (PDT) Date: Wed, 24 Jul 2013 02:19:04 +0200 From: Mateusz Guzik To: Yuri Subject: Re: Should process run under chroot(8) still see mounts on the original system? Message-ID: <20130724001904.GB19249@dft-labs.eu> References: <51EF0EEE.8030000@rawbw.com> <20130723233102.GA19249@dft-labs.eu> <51EF1552.4050003@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <51EF1552.4050003@rawbw.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 00:19:10 -0000 On Tue, Jul 23, 2013 at 04:44:18PM -0700, Yuri wrote: > On 07/23/2013 16:31, Mateusz Guzik wrote: > >Of course then you may have some unnecessary separation but that I > >believe can be simply worked out if it turns out to be problematic. > > > jail would completely separate two systems. In my case this app also > communicates through files that it creates and host app reads > through symbolic links. It might also be assuming that it runs on > the same host and maybe is unable to connect to X server other than > through the shared memory. > 1. fs level cooperation is not going to be affected in any way. for all practical purposes you can assume fs-wise jail is a chroot with ".." escape disabled 2. typically local applications connect to X server over unix socket, i.e. something you would have to expose in the jail anyway (by e.g. mount -t nullfs /tmp /path/to/jail/tmp) Of course I can be wrong here, but looks like jail is a drop-in replacement here. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 24 05:13:17 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 000F786F for ; Wed, 24 Jul 2013 05:13:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9033A29B3 for ; Wed, 24 Jul 2013 05:13:16 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id q58so744907wes.34 for ; Tue, 23 Jul 2013 22:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=uwkCR3dVDaEiopoogRxy5d75npGjK3Jk7f0pDFSDxfw=; b=GfjTtFEkxYXmsMmDjM97VHtfICO+eSKZjzm32xKfy5NOEE9fgKSnv39B5Aqbc1sQJw dJ1hOFUHvGs8Ejo5QM+LmWCkJ+F9wtRR9pdwhicmS04wpyBYi/ICXwTgi3z+r59hBzKN G/98pymf9N0YRpKzLL6qhvt1oDwgLPIv030hDT5t6UaqSeHjgrTmgvCfpeCYx6Gd3kRJ ID3JJ96I8qU7EZYxBulzrZkwYuMkPZjX+YIC2d2weHYtkdkUzjouXidV5LZE3Vt2TzBB mh9E+OY9M12iXdhvQ41oFJc2v21wfb9TB2GTACklD1Krd+9l8lPjJeOWnSh1nsJtbe0l Tr6g== MIME-Version: 1.0 X-Received: by 10.194.92.6 with SMTP id ci6mr1307532wjb.79.1374642794712; Tue, 23 Jul 2013 22:13:14 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Tue, 23 Jul 2013 22:13:14 -0700 (PDT) In-Reply-To: <11109.1374623313@server1.tristatelogic.com> References: <11109.1374623313@server1.tristatelogic.com> Date: Tue, 23 Jul 2013 22:13:14 -0700 X-Google-Sender-Auth: n2eGnzwlc4ocgMYIE9fduIIK0SY Message-ID: Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon From: Adrian Chadd To: "Ronald F. Guilmette" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 05:13:17 -0000 Hi, Well, I've done this before. More than once. I'm glad that you've stuck through helping me understand what nc is doing; I'm unfortunately busy doing other things What you end up doing is: * tracking the state of the two sockets, both for read EOF and write EOF; * whenever you get an EOF from one of the above four conditions, you see whether you can still make progress. If so, you don't close the socket - you just stop registering for that event. (Eg, if you see read EOF on a socket, stop registering for read) * if you see that both sides are read EOF'ed, then you can't possibly make any more progress, right? * .. no, you also have to THEN ensure that all the data you have queued is written, OR that you hit write EOF (and thus can't make any more progress anyway) _then_ you shut things down. Anyway. Leave it with me. Bug me if I don't commit either your fix, or rearchitect it to do what I said above (and then test it, obviously :) -adrian From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 24 18:13:21 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 50E22A98 for ; Wed, 24 Jul 2013 18:13:21 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from www.rawbandwidth.com (www.rawbandwidth.com [198.144.193.1]) by mx1.freebsd.org (Postfix) with ESMTP id 3E4CE232D for ; Wed, 24 Jul 2013 18:13:20 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by www.rawbandwidth.com (8.14.4/8.14.4) with ESMTP id r6OIDK7b043848 for ; Wed, 24 Jul 2013 11:13:20 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <51F01940.2020402@rawbw.com> Date: Wed, 24 Jul 2013 11:13:20 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Hackers Subject: DTrace copyin with struct doesn't work? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 18:13:21 -0000 This simple .d script fails: ---script begin--- #!/usr/sbin/dtrace -s struct my_args { int ii; }; fbt::sys_select:entry { printf("sys_select %i", ((struct my_args*)copyin(arg1, sizeof (struct my_args)))->ii); } ---script end--- dtrace: error on enabled probe ID 1 (ID 33598: fbt:kernel:sys_select:entry): invalid address (0xffffff82ff0799d8) in action #1 at DIF offset 40 dtrace: error on enabled probe ID 1 (ID 33598: fbt:kernel:sys_select:entry): invalid address (0xffffff82fefb19d8) in action #1 at DIF offset 40 Function sys_select is defined in kern/sys_generic.c: int sys_select(struct thread *td, struct select_args *uap) arg1 in DTrace script should correspond to uap argument of sys_select, and dereferencing should always produce an int. Yuri From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 24 18:33:57 2013 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5BA925EA for ; Wed, 24 Jul 2013 18:33:57 +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 A35662449 for ; Wed, 24 Jul 2013 18:33:56 +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 VAA25370; Wed, 24 Jul 2013 21:33:46 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V23sg-0008mY-2y; Wed, 24 Jul 2013 21:33:46 +0300 Message-ID: <51F01DD2.6060308@FreeBSD.org> Date: Wed, 24 Jul 2013 21:32:50 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yuri Subject: Re: DTrace copyin with struct doesn't work? References: <51F01940.2020402@rawbw.com> In-Reply-To: <51F01940.2020402@rawbw.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 18:33:57 -0000 on 24/07/2013 21:13 Yuri said the following: > This simple .d script fails: > > ---script begin--- > #!/usr/sbin/dtrace -s > > struct my_args { > int ii; > }; > > fbt::sys_select:entry > { > printf("sys_select %i", ((struct my_args*)copyin(arg1, sizeof (struct > my_args)))->ii); > } > ---script end--- > > dtrace: error on enabled probe ID 1 (ID 33598: fbt:kernel:sys_select:entry): > invalid address (0xffffff82ff0799d8) in action #1 at DIF offset 40 > dtrace: error on enabled probe ID 1 (ID 33598: fbt:kernel:sys_select:entry): > invalid address (0xffffff82fefb19d8) in action #1 at DIF offset 40 > > Function sys_select is defined in kern/sys_generic.c: > int > sys_select(struct thread *td, struct select_args *uap) >From sys_select code it is clear that uap points to something that is already copied in. Unlike some fields within select_args. > arg1 in DTrace script should correspond to uap argument of sys_select, and > dereferencing should always produce an int. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 24 18:51:47 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4C407104; Wed, 24 Jul 2013 18:51:47 +0000 (UTC) (envelope-from leonerd@leonerd.org.uk) Received: from cel.leonerd.org.uk (cel.leonerd.org.uk [IPv6:2001:8b0:3f7::2]) by mx1.freebsd.org (Postfix) with ESMTP id 08A72258C; Wed, 24 Jul 2013 18:51:47 +0000 (UTC) Received: from shy.leonerd.org.uk (8.9.7.8.3.c.e.f.f.f.2.8.9.a.e.8.3.4.0.0.7.f.3.0.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:3f7:43:8ea9:82ff:fec3:8798]) by cel.leonerd.org.uk (Postfix) with ESMTPSA id CEC191BD94; Wed, 24 Jul 2013 19:51:44 +0100 (BST) Date: Wed, 24 Jul 2013 17:48:21 +0100 From: Paul "LeoNerd" Evans To: freebsd-hackers@freebsd.org, Adrian Chadd , Eugen-Andrei Gavriloaie , Jilles Tjoelker Subject: Kevent EV_DROP notification support Message-ID: <20130724174821.2e71f382@shy.leonerd.org.uk> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA256; boundary="Sig_/oGiyQ.gfPd/UUtElkObTvzA"; protocol="application/pgp-signature" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 18:51:47 -0000 --Sig_/oGiyQ.gfPd/UUtElkObTvzA Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Did we ever reach a consensus about this issue? We discussed it somewhat and more or less came to a conclusion that "yes this would be nice". Has anyone got as far as to step up and say they'll implement something yet? I have some good ideas on testing it and making use of it from userland, code and so on.. and documentation. I know FreeBSD-types like documentation :) Just we don't have an actual -implementation- yet. --=20 Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ --Sig_/oGiyQ.gfPd/UUtElkObTvzA Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlHwBVYACgkQ4y9efBOfZ0gZEgD7BYR+Yg293dXOJL26ArMclaZM 6xR+sNbiXTT50EN5V/kA/RaArOQi/LKuqlh83ydOJHhockqZs88YgjYemOMqRf46 =pViW -----END PGP SIGNATURE----- --Sig_/oGiyQ.gfPd/UUtElkObTvzA-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 24 22:35:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A25313FC; Wed, 24 Jul 2013 22:35:20 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 54D802FB1; Wed, 24 Jul 2013 22:35:20 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id fb19so14624837obc.9 for ; Wed, 24 Jul 2013 15:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pOCzLiuKd1ibPU7fSZEMbQaqzFFolWANlKsPVycHvXU=; b=CpepZoWPcyNBrI2iHLW6/py5yBCbd0NzoPG9TG2ViHGGMvB2+XvAjM4lZxELw74Evr JYTDVgOHf/OBE2g+1ge6vgjR6uidp9yAgzqc6A1AnNi4fjidGAvODj8u81up7V7pDDYF Leg8HHlsSmwBrYqvTp78jqWTZw85ByL3s7act65QURVnI8yHvN9/y3CW/h04b5COhj0+ NNPxmwHq4vRqKSU1c0h00FbyfM0ASKo4MxjBL4R8zSuIHAvyARULH8O8r2eb0/fuQO1p en4nCe6huo9z9KAnAo7TSdFfsPO6+NmYPrtJPwSryxd/JOmTV9fIUmJhLL5Ppa1OYM3a riug== MIME-Version: 1.0 X-Received: by 10.60.125.100 with SMTP id mp4mr39048715oeb.60.1374705319592; Wed, 24 Jul 2013 15:35:19 -0700 (PDT) Received: by 10.182.115.194 with HTTP; Wed, 24 Jul 2013 15:35:19 -0700 (PDT) Date: Wed, 24 Jul 2013 18:35:19 -0400 Message-ID: Subject: Kern.hz= +1 hertz at anything 2500 and above. From: Super Bisquit To: FreeBSD PowerPC ML , FreeBSD Hackers , freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 22:35:20 -0000 http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051789.html This is the thread that I was referring to earlier. Since the patch is for 2009, what are the chances it would work with 10.x or 9.x? On PowerPC machines with a low MHz rate- or any machine with a CPU rate of 800 MHz or less- increasing the kern.hz improves performance and cuts down on latency. I am building audio applications and suites that are used in different projects. A G3 based machine should be able to run a kernel with kern.hz=5000 with no problem. Unfortunately, this cannot be done. @PowerPC: some of you may find that performance does increase at a higher kern.hz rate. @Hackers & Current: What's the chance that the default rate limit can be raised to 5k? From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 24 23:43:43 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0B07E476; Wed, 24 Jul 2013 23:43:43 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id DDB1021D4; Wed, 24 Jul 2013 23:43:41 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 80D213B73C; Wed, 24 Jul 2013 16:43:37 -0700 (PDT) From: "Ronald F. Guilmette" To: Adrian Chadd Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon In-Reply-To: Date: Wed, 24 Jul 2013 16:43:37 -0700 Message-ID: <59915.1374709417@server1.tristatelogic.com> Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 23:43:43 -0000 In message , you wrote: >Hi, > >Well, I've done this before. More than once. I'm glad that you've >stuck through helping me understand what nc is doing; I'm >unfortunately busy doing other things > >What you end up doing is: > >* tracking the state of the two sockets, both for read EOF and write EOF; >* whenever you get an EOF from one of the above four conditions, you >see whether you can still make progress. If so, you don't close the >socket - you just stop registering for that event. (Eg, if you see >read EOF on a socket, stop registering for read) >* if you see that both sides are read EOF'ed, then you can't possibly >make any more progress, right? >* .. no, you also have to THEN ensure that all the data you have >queued is written, OR that you hit write EOF (and thus can't make any >more progress anyway) > >_then_ you shut things down. > >Anyway. Leave it with me. Bug me if I don't commit either your fix, or >rearchitect it to do what I said above (and then test it, obviously :) Thank you. Please consider yourself bugged. (1/2 :-) From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 25 00:16:24 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 22149A6C; Thu, 25 Jul 2013 00:16:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5CAD722C2; Thu, 25 Jul 2013 00:16:23 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id b13so1046363wgh.7 for ; Wed, 24 Jul 2013 17:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TzexVlQiR9mG3cTHzwSuiuEJNw3quhMjW8dJ5xYCjPg=; b=CTqBdsTRgSFLZzEX/jdbvhIPpZUZskhTB7fVQVBozWf+b+xZR+1Fic3CRMENsDzW2u sljRdO6r6EtdzjcYCJVZ5ZKzbnviRuXbCJ3kYXWLTqIF816i1LaiiCxlaq9GvYJrUFML HQBNWs8j3FOELLqT4zijxDH84YEIVkVkQmHKhXI7iiM8/jCS21gJwRnjd/DUfEL6YsYX Ec9P8tRR9LWXXXs4pop/uzzF/M6bgL2+X6GL/T2mu4GfGwYDK9Q2kTaybhbZKU0C5JNO pYfXjy316JelmhhUwovwgOb+30DOhHFpSIQiuTgIFiKIr/fFm3mHJBdf4Im+69tnY4ww X3bw== MIME-Version: 1.0 X-Received: by 10.194.92.6 with SMTP id ci6mr4577182wjb.79.1374711381631; Wed, 24 Jul 2013 17:16:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Wed, 24 Jul 2013 17:16:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Jul 2013 17:16:21 -0700 X-Google-Sender-Auth: fsisARJh9DVWyxUH3IDFNYPF6pA Message-ID: Subject: Re: Kern.hz= +1 hertz at anything 2500 and above. From: Adrian Chadd To: Super Bisquit Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , freebsd-current , FreeBSD PowerPC ML X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 00:16:24 -0000 Well, why is it reducing latency? That's the thing you should investigate. Is it because processes aren't getting enough time? or too much time? Or the audio device isn't getting enough time to run? etc. -adrian On 24 July 2013 15:35, Super Bisquit wrote: > http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051789.html > > This is the thread that I was referring to earlier. Since the patch is for > 2009, what are the chances it would work with 10.x or 9.x? > > On PowerPC machines with a low MHz rate- or any machine with a CPU rate of > 800 MHz or less- increasing the kern.hz improves performance and cuts down > on latency. I am building audio applications and suites that are used in > different projects. A G3 based machine should be able to run a kernel with > kern.hz=5000 with no problem. Unfortunately, this cannot be done. > > @PowerPC: some of you may find that performance does increase at a higher > kern.hz rate. > > @Hackers & Current: What's the chance that the default rate limit can be > raised to 5k? > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 25 00:21:00 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 64726CBB for ; Thu, 25 Jul 2013 00:21:00 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F07C022F9 for ; Thu, 25 Jul 2013 00:20:59 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id q56so26910wes.35 for ; Wed, 24 Jul 2013 17:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=y5yZwfSKPNC4O6/KpkA2e2K10zGaaMYawY9wwNWqRMo=; b=Qt3B8gbBFvgsrQEsc/EPtYJ2S8E8aWdoKdgVPo5ttwJhq6rASS9I9toxlkaeoYw/kg 7rTCXEVlY/aCFd5ovxddff6NsspS8UCSHreQpMnlpmlW+99KmHzi+zO+vBhoRCGLOVEE VUNU1pnyC34hn5NHC+Ud+AnyiriZVs/aLA0uzDLxsdhl2Or6NA499uJ3xs8kT1j1QSPb F2Piv6a0c7JSzDinF29I2z4bU8BADeH9D/UTK4JJumHtrl2zk98MOwzxTr62YuY9HU3y 65unNvWCExbs6yhKfMjG6lgLBcSLloqzFUqLdVF5Vsm89KTTRL9d0IbATxN1CSte2EGl ZewQ== MIME-Version: 1.0 X-Received: by 10.180.39.212 with SMTP id r20mr106857wik.30.1374711658378; Wed, 24 Jul 2013 17:20:58 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Wed, 24 Jul 2013 17:20:58 -0700 (PDT) In-Reply-To: <59915.1374709417@server1.tristatelogic.com> References: <59915.1374709417@server1.tristatelogic.com> Date: Wed, 24 Jul 2013 17:20:58 -0700 X-Google-Sender-Auth: gHJBtTbDzdq0tRareKPgdHzRO8M Message-ID: Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon From: Adrian Chadd To: "Ronald F. Guilmette" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 00:21:00 -0000 On 24 July 2013 16:43, Ronald F. Guilmette wrote: > > Thank you. > > Please consider yourself bugged. > (1/2 :-) :-) I'm currently trying to figure out ixgbe and lagg bugs (separately and together.) Once I've done that, I'll look at nc. Just keep bugging me until I do. -adrian From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 25 00:21:40 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BC03ADAB for ; Thu, 25 Jul 2013 00:21:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 538E02307 for ; Thu, 25 Jul 2013 00:21:40 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id m6so1123749wiv.15 for ; Wed, 24 Jul 2013 17:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wx+e4Q/INHQD/KVoAv1iNjYR6DV7ZLaEOKEenbxPO1I=; b=S6lh+Hg//reojKIZTvsnA0BfT8scyd2L51cJwiFJAiSL+DJdnUcC7vQ9ZXvX+5qSuj rsRLMRD9aBkHAZiFXO8V02NzWDlbKpBoDdR7C2804QSyMWIl5Z2VsuUC/UR22rlj680T j6XryKez8ADYDs5Jp3qZCQfIBTGM2nkF23obXyqmDWlreq6B2gJkRb9nW532zJdgG9EG 61XavXksYakOBdEI3NrWszWCmDMuHoDFiUaBnqcz+tOpEDqD1ZEG22gvwtdsWKRiUnoe NaS5+TlqGYvlpHaczKnFrtNDZtiwcRFSKNrAG28ES1OQp+yZGT/USUkEpM/bT9V898N6 QVdQ== MIME-Version: 1.0 X-Received: by 10.180.20.116 with SMTP id m20mr79264wie.46.1374711698657; Wed, 24 Jul 2013 17:21:38 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Wed, 24 Jul 2013 17:21:38 -0700 (PDT) In-Reply-To: <20130724174821.2e71f382@shy.leonerd.org.uk> References: <20130724174821.2e71f382@shy.leonerd.org.uk> Date: Wed, 24 Jul 2013 17:21:38 -0700 X-Google-Sender-Auth: DkAIM1GlNgAZADoAi2SMtVwh4ko Message-ID: Subject: Re: Kevent EV_DROP notification support From: Adrian Chadd To: Paul LeoNerd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Jilles Tjoelker , Eugen-Andrei Gavriloaie X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 00:21:40 -0000 I now work at a place where I have to care about this. So, if someone provides me with a sane implementation and API description, I'll review and commit it. -adrian On 24 July 2013 09:48, Paul LeoNerd wrote: > Did we ever reach a consensus about this issue? We discussed it > somewhat and more or less came to a conclusion that "yes this would be > nice". > > Has anyone got as far as to step up and say they'll implement something > yet? I have some good ideas on testing it and making use of it from > userland, code and so on.. and documentation. I know FreeBSD-types like > documentation :) Just we don't have an actual -implementation- yet. > > -- > Paul "LeoNerd" Evans > > leonerd@leonerd.org.uk > ICQ# 4135350 | Registered Linux# 179460 > http://www.leonerd.org.uk/ From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 25 01:04:18 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 43ED8606; Thu, 25 Jul 2013 01:04:18 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB0102462; Thu, 25 Jul 2013 01:04:17 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id j6so2863393oag.29 for ; Wed, 24 Jul 2013 18:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=2uN7lFesbOCR5N86YX2eUGdhDur1ZJFzmHKl1OtS+Oo=; b=BPk7dwXCJZldRhJOlkubjjSAhcQomMCVDzJ3E2JqL+wIb48bx51wgRi1yh5oOKlnLI iOAvL0FTUDmwe7HXcBYklrkDLynC7thZgBnZX81bquWYH2vJjffDZ6dFgFyDeSGzBMuF Vgwwhxgyq0ozktgr8IDhZm9hjC53oIqQc+Qehyg1hoPTGwn6Az5ytV1185evjm6bRUQa sjveWACp2JuuAQyJSN123IHXc0fiWGBMqSXqWDMGEODM6UiMSGSFVBaj0dlao8yVhIvn MKpqJufDAsEnYhLGhFg3koXTiK5yxrOm0GxDslMYFd5qECVwC8+hY4IsFAEjjAuSdamx uleA== MIME-Version: 1.0 X-Received: by 10.60.125.100 with SMTP id mp4mr39510828oeb.60.1374714257003; Wed, 24 Jul 2013 18:04:17 -0700 (PDT) Received: by 10.182.115.194 with HTTP; Wed, 24 Jul 2013 18:04:16 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Jul 2013 21:04:16 -0400 Message-ID: Subject: Re: Kern.hz= +1 hertz at anything 2500 and above. From: Super Bisquit To: Adrian Chadd , FreeBSD PowerPC ML , freebsd-current , FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 01:04:18 -0000 When I started with FreeBSD on a G3 B&W, I noticed that the performance improved with a higher kern.hz rating. Unless the future holds an emu20k2, there will be RAM used from the motherboard. 1. I will need a real-time or a faster kernel- hence the high rate wanted- because the devices to be built will be used in an active environment: art, music, audio control. 2. Any system with limited memory and a low CPU hertz rate benefits from the higher kern.hz setting. 3. Why not? If it works for PowerPC, SPARC64, AMD64, and i386 then it may work for other architectures. 4. Some applications may be ran from within a jail. On Wed, Jul 24, 2013 at 8:16 PM, Adrian Chadd wrote: > Well, why is it reducing latency? That's the thing you should investigate. > > Is it because processes aren't getting enough time? or too much time? > Or the audio device isn't getting enough time to run? etc. > > > > -adrian > > On 24 July 2013 15:35, Super Bisquit wrote: > > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051789.html > > > > This is the thread that I was referring to earlier. Since the patch is > for > > 2009, what are the chances it would work with 10.x or 9.x? > > > > On PowerPC machines with a low MHz rate- or any machine with a CPU rate > of > > 800 MHz or less- increasing the kern.hz improves performance and cuts > down > > on latency. I am building audio applications and suites that are used in > > different projects. A G3 based machine should be able to run a kernel > with > > kern.hz=5000 with no problem. Unfortunately, this cannot be done. > > > > @PowerPC: some of you may find that performance does increase at a higher > > kern.hz rate. > > > > @Hackers & Current: What's the chance that the default rate limit can be > > raised to 5k? > > _______________________________________________ > > freebsd-ppc@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 25 10:13:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4E223AA2; Thu, 25 Jul 2013 10:13:20 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ABA9A2DA1; Thu, 25 Jul 2013 10:13:19 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7) with ESMTP id r6P9p2b2012860; Thu, 25 Jul 2013 11:51:02 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7/Submit) with ESMTP id r6P9p2UC012857; Thu, 25 Jul 2013 11:51:02 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 25 Jul 2013 11:51:02 +0200 (CEST) From: Wojciech Puchar To: Super Bisquit Subject: Re: Kern.hz= +1 hertz at anything 2500 and above. In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 25 Jul 2013 11:51:02 +0200 (CEST) Cc: FreeBSD Hackers , Adrian Chadd , freebsd-current , FreeBSD PowerPC ML X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 10:13:20 -0000 > improved with a higher kern.hz rating. Unless the future holds an emu20k2, > there will be RAM used from the motherboard. > 1. I will need a real-time or a faster kernel- hence the high rate wanted- > because the devices to be built will be used in an active environment: art, > music, audio control. > 2. Any system with limited memory and a low CPU hertz rate benefits from > the higher kern.hz setting. rather opposite. more kern.hz=more interrupts. > 3. Why not? If it works for PowerPC, SPARC64, AMD64, and i386 then it may > work for other architectures. > 4. Some applications may be ran from within a jail. > > > On Wed, Jul 24, 2013 at 8:16 PM, Adrian Chadd wrote: > >> Well, why is it reducing latency? That's the thing you should investigate. >> >> Is it because processes aren't getting enough time? or too much time? >> Or the audio device isn't getting enough time to run? etc. >> >> >> >> -adrian >> >> On 24 July 2013 15:35, Super Bisquit wrote: >>> >> http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051789.html >>> >>> This is the thread that I was referring to earlier. Since the patch is >> for >>> 2009, what are the chances it would work with 10.x or 9.x? >>> >>> On PowerPC machines with a low MHz rate- or any machine with a CPU rate >> of >>> 800 MHz or less- increasing the kern.hz improves performance and cuts >> down >>> on latency. I am building audio applications and suites that are used in >>> different projects. A G3 based machine should be able to run a kernel >> with >>> kern.hz=5000 with no problem. Unfortunately, this cannot be done. >>> >>> @PowerPC: some of you may find that performance does increase at a higher >>> kern.hz rate. >>> >>> @Hackers & Current: What's the chance that the default rate limit can be >>> raised to 5k? >>> _______________________________________________ >>> freebsd-ppc@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc >>> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 25 14:57:47 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DB3C59CA for ; Thu, 25 Jul 2013 14:57:46 +0000 (UTC) (envelope-from h.tugrul.erdogan@gmail.com) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A41E2CF4 for ; Thu, 25 Jul 2013 14:57:46 +0000 (UTC) Received: by mail-ve0-f170.google.com with SMTP id 14so541428vea.29 for ; Thu, 25 Jul 2013 07:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=iq4ID92iyvrDlGDbq96s6Jq1VCvtVwKcUuKeB+v5Srw=; b=a7QYPln3vOEiTzw8ycNaxy5fEMGp3CjGAoFCWyfrV8odQO6v16uM9THTQT1SUTa7IH uzZUe2waZrL0ZHOLZUo4Se28E4Xh2ZIkkrc/b2ypNN2llXU5ncM2scUbkIviSC20J20V ZlzTWPLLTfsDeHUIxGmxJNEhqwl9IksZx0cWjbUGx1y/1Y2RTtoDvakSOfyjzxTDqheM ZYTbWVnJqAIQ/P44Ytqm/K9hyzcKsNlZZuVItNBlOWUrvrhSKpaTi89nX5H5R9/ML3zA BMTUOq7mR668v2jGZIGsh/K5cM/r81IBGHu2okaw3U5Kk5EenpsagTNU2aPmMoIDX+h4 Kl0A== MIME-Version: 1.0 X-Received: by 10.58.69.65 with SMTP id c1mr17569375veu.88.1374764265738; Thu, 25 Jul 2013 07:57:45 -0700 (PDT) Received: by 10.58.54.103 with HTTP; Thu, 25 Jul 2013 07:57:45 -0700 (PDT) Date: Thu, 25 Jul 2013 17:57:45 +0300 Message-ID: Subject: panic: kmem_map too small at heavy packet traffic From: Tugrul Erdogan To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 14:57:47 -0000 howdy all, At my work, I am using 10.0-CURRENT on Intel(R) Xeon(R) E5620 with 16GB ram. I am taking "panic: kmem_malloc(-548663296): kmem_map too small: 539459584 total allocated" message with configuration below: [root@ ~]# sysctl vm.kmem_size_min vm.kmem_size_max vm.kmem_size vm.kmem_size_scale vm.kmem_size_min: 0 vm.kmem_size_max: 329853485875 vm.kmem_size: 16686845952 vm.kmem_size_scale: 1 [root@ ~]# sysctl hw.physmem hw.usermem hw.realmem hw.physmem: 17151787008 hw.usermem: 8282652672 hw.realmem: 18253611008 [root@ ~]# sysctl hw.pagesize hw.pagesizes hw.availpages hw.pagesize: 4096 hw.pagesizes: 4096 2097152 0 hw.availpages: 4187448 When I compare vmstat and netstat output of boot time result and subsequent result, the major difference are seemed at: pf_temp 0 0K - 79309736 128 | pf_temp 1077640 134705K - 84330076 128 and after the panic at the core dump file the major vmstat difference is: temp 110 15K - 76212305 16,32,64,128,256 | temp 117 6742215K - 655115 16,32,64,128,2 When I explore the source code of kernel (at vm_kern.c and vm_map.c), I see that the panic can occur with the cases at below: * negative malloc size parameter * longer than free buffer respect to kmem_map min_offset and max_offset values * try to allocate when the root entry of map is the rightmost entry of map * try to allocate bigger than map's max_free value I think the panic occurs at mbuf creation process when calling malloc() as a result of couldn't be able to allocate memory; but I don't understand why one of this panic case activating? The memory is almost empty but the device is saying kmem_map small when using about 0.5GB memory purely. How can i solve this panic problem? Thank you all for your time. -- Best Wishes, Tugrul Erdogan From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 25 16:11:39 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BE406CF8; Thu, 25 Jul 2013 16:11:39 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 04C32217E; Thu, 25 Jul 2013 16:11:38 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id b13so1846798wgh.19 for ; Thu, 25 Jul 2013 09:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=giv0WWIGpI3VrGnbHPt7xc3L6V+CXUsSA5jYbeAPgZY=; b=EcvK1suJsy8bt/l9zJ+y0GrDG4zuukGuxdOqOZw2SkiDjGKH+vaneXYK5SJ5eGZ5X8 YhGoY0Tqn01NIeFbYriDBAYdYHrmQ/wC8X6Pn8rIy/72J/ho/YPUnL7CtNKVP2oYvQin oR1F3f3TCkk+uldjlmf9tmHVYd7zfMliqxzSlubruBXGAm6pVHAVha2FP+gXiVks38BD a/qsv9IAZQ+SeUnBnHLfm1xqlGiBRgxOaNnhu8nGWO3Xxx7/1vRQ9WFQYuXJX2wq+9j8 LaDMlcFnplZmx4hae25jiMZD2x+xLQWUMLrK5vltU7I6oOl/wTpVuOtbfbEDMCG0jQE1 eKWg== MIME-Version: 1.0 X-Received: by 10.194.92.6 with SMTP id ci6mr7227233wjb.79.1374768697270; Thu, 25 Jul 2013 09:11:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Thu, 25 Jul 2013 09:11:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Jul 2013 09:11:37 -0700 X-Google-Sender-Auth: -vAecfRGuNGwy-4rjpi6FHKbS4E Message-ID: Subject: Re: Kern.hz= +1 hertz at anything 2500 and above. From: Adrian Chadd To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 Cc: Super Bisquit , freebsd-current , FreeBSD Hackers , FreeBSD PowerPC ML X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 16:11:39 -0000 On 25 July 2013 02:51, Wojciech Puchar wrote: >> improved with a higher kern.hz rating. Unless the future holds an emu20k2, >> there will be RAM used from the motherboard. >> 1. I will need a real-time or a faster kernel- hence the high rate wanted- >> because the devices to be built will be used in an active environment: >> art, >> music, audio control. >> 2. Any system with limited memory and a low CPU hertz rate benefits from >> the higher kern.hz setting. > rather opposite. more kern.hz=more interrupts. Right. More hz == more interrupts and less ability for a CPU-bound process to chew all the CPU. So is it a scheduling issue, where you have multiple CPU bound userland processes that aren't being fair and consuming all the CPU? Is it that your device driver(s) aren't interrupting correctly, relying on the hz tick to make up the slack, etc. Is it a busted halt loop, which is being papered over with hz ticks? Have you tried -10 on that kit, with the more aggressive clock/timer code that won't interrupt unless it needs to? Has that changed things? -adrian From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 25 20:31:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 326FE6F2; Thu, 25 Jul 2013 20:31:55 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C3EFA2E64; Thu, 25 Jul 2013 20:31:54 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id n12so5499057oag.36 for ; Thu, 25 Jul 2013 13:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MWXqU+js3bXhIe/rtkwsupkW59SZPsfz2LuMMeYKeTs=; b=qSmbQWpn41VlKDsHvI9XN3X0O/twhX5lmqx22ipULqUNvahKpzTUC8wLuJG1meRXDL z9Hn1iv3E6T2Lxv/HJEIx6lgM32m0znBVclEk9QcnNcbMvdoHHz3K9wuAEGi1cbVNrpO TTl9SRBGEDrM/dmw/HSRYt4835XIK19Jmhbqi6nUFwLMdDXsYcCOInYt7UGOc6Tis0gd WvLFQ4Adga8/HfqTM1v98iq+yDk0UPR3M61kW6UzDxJthLS+fUzpCfi8k129VberpJah kjt5mMMBul54WsjaD0zQd23imL0jWTsuudvBdvfc7LVFB5trZlDYKsZm66mxB6wLxVcl Swxg== MIME-Version: 1.0 X-Received: by 10.60.52.78 with SMTP id r14mr45103404oeo.9.1374784314010; Thu, 25 Jul 2013 13:31:54 -0700 (PDT) Received: by 10.182.115.194 with HTTP; Thu, 25 Jul 2013 13:31:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Jul 2013 16:31:53 -0400 Message-ID: Subject: Re: Kern.hz= +1 hertz at anything 2500 and above. From: Super Bisquit To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Wojciech Puchar , freebsd-current , FreeBSD Hackers , FreeBSD PowerPC ML X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 20:31:55 -0000 I haven't done much messing with scheduling. It is set at the default ULE for this machine. On Thu, Jul 25, 2013 at 12:11 PM, Adrian Chadd wrote: > On 25 July 2013 02:51, Wojciech Puchar > wrote: > >> improved with a higher kern.hz rating. Unless the future holds an > emu20k2, > >> there will be RAM used from the motherboard. > >> 1. I will need a real-time or a faster kernel- hence the high rate > wanted- > >> because the devices to be built will be used in an active environment: > >> art, > >> music, audio control. > >> 2. Any system with limited memory and a low CPU hertz rate benefits from > >> the higher kern.hz setting. > > > rather opposite. more kern.hz=more interrupts. > > Right. > > More hz == more interrupts and less ability for a CPU-bound process to > chew all the CPU. > > So is it a scheduling issue, where you have multiple CPU bound > userland processes that aren't being fair and consuming all the CPU? > Is it that your device driver(s) aren't interrupting correctly, > relying on the hz tick to make up the slack, etc. > > Is it a busted halt loop, which is being papered over with hz ticks? > > Have you tried -10 on that kit, with the more aggressive clock/timer > code that won't interrupt unless it needs to? Has that changed things? > > > > -adrian > From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 26 07:45:56 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 23F9AEE8 for ; Fri, 26 Jul 2013 07:45:56 +0000 (UTC) (envelope-from h.tugrul.erdogan@gmail.com) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D80092A3E for ; Fri, 26 Jul 2013 07:45:55 +0000 (UTC) Received: by mail-ve0-f178.google.com with SMTP id ox1so396508veb.9 for ; Fri, 26 Jul 2013 00:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7BejTPjwrJ7F+apJV+1KPAXaQbYv8Aad5zGpmzlbcnc=; b=Z+YjynAvIQSOACXF1xL9b96/MVUM4+qv9mw95V+G98Ev0G59QJGO/dtC0N90poOeVv AQ4/u2WCY3JZZe023+7AqgA/SDdxXxoHEkMDHcdEiATLgKpouvT81Xm2vNY71R0wu5Zj N0yAt4DzkKkFxgGaq6MV6w32vDqQwOpI5EmefFheP8UyaPMt3N5QK9kj1a7jwYL/2GRf htK8J2zEgLfYvyQ5+CO8jLg4udu0BIusqJOYm6KQ7p204XI7N8DBzgLGE8Cw06Tl77KR A1EOYBe28rjHlwvmt9sFDZulpfUDriGZyboMoeKVg0k38Fy2bUt5w1Fv4BIu+hEKFA3n +rfQ== MIME-Version: 1.0 X-Received: by 10.220.175.84 with SMTP id w20mr2563370vcz.84.1374824754948; Fri, 26 Jul 2013 00:45:54 -0700 (PDT) Received: by 10.58.54.103 with HTTP; Fri, 26 Jul 2013 00:45:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Jul 2013 10:45:54 +0300 Message-ID: Subject: Re: panic: kmem_map too small at heavy packet traffic From: Tugrul Erdogan To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 07:45:56 -0000 Specifically, I am taking this panic when doing ip spoof attack while syn-proxy activated. The output of system arguments below: kern.malloc_count: 315 vm.md_malloc_wait: 0 vfs.bufmallocspace: 0 vfs.maxmallocbufspace: 86269952 vm.kmem_size: 16686845952 vm.kmem_size_min: 0 vm.kmem_size_max: 329853485875 vm.kmem_size_scale: 1 vm.kmem_map_size: 543973376 vm.kmem_map_free: 15974895616 kern.maxvnodes: 350097 kern.minvnodes: 87524 vfs.numvnodes: 112329 vfs.wantfreevnodes: 87524 vfs.freevnodes: 87502 [root@ ~]# pfctl -si No ALTQ support in kernel ALTQ related functions disabled Status: Enabled for 0 days 00:17:39 Debug: Urgent State Table Total Rate current entries 5142886 searches 26982141 25478.9/s inserts 29055053 27436.3/s removals 24218654 22869.4/s Counters match 24901305 23514.0/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 0 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 18 0.0/s proto-cksum 0 0.0/s state-mismatch 0 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 29378439 27741.7/s [root@~]# panic: kmem_malloc(-1 814 425 600): kmem_map too small: 543 956 992 to tal allocated cpuid = 8 Uptime: 1d18h2m14s (ada0:ahcich1:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00 (ada0:ahcich1:0:0:0): CAM status: CCB request is in progress (ada0:ahcich1:0:0:0): Error 5, Retries exhausted (ada0:ahcich1:0:0:0): Synchronize cache failed (ada1:ahcich2:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00 (ada1:ahcich2:0:0:0): CAM status: CCB request is in progress (ada1:ahcich2:0:0:0): Error 5, Retries exhausted (ada1:ahcich2:0:0:0): Synchronize cache failed Dumping 8243 out of 16357 MB:..1%..11% On Thu, Jul 25, 2013 at 5:57 PM, Tugrul Erdogan wrote: > howdy all, > > At my work, I am using 10.0-CURRENT on Intel(R) Xeon(R) E5620 with 16GB > ram. I am taking > > "panic: kmem_malloc(-548663296): kmem_map too small: 539459584 total allocated" > > message with configuration below: > > [root@ ~]# sysctl vm.kmem_size_min vm.kmem_size_max vm.kmem_size vm.kmem_size_scale > > vm.kmem_size_min: 0 > vm.kmem_size_max: 329853485875 > vm.kmem_size: 16686845952 > vm.kmem_size_scale: 1 > [root@ ~]# sysctl hw.physmem hw.usermem hw.realmem > hw.physmem: 17151787008 > hw.usermem: 8282652672 > > hw.realmem: 18253611008 > [root@ ~]# sysctl hw.pagesize hw.pagesizes hw.availpages > hw.pagesize: 4096 > hw.pagesizes: 4096 2097152 0 > hw.availpages: 4187448 > > > When I compare vmstat and netstat output of boot time result and subsequent result, the major difference are seemed at: > > pf_temp 0 0K - 79309736 128 | pf_temp 1077640 134705K - 84330076 128 > > and after the panic at the core dump file the major vmstat difference is: > > temp 110 15K - 76212305 16,32,64,128,256 | temp 117 6742215K - 655115 16,32,64,128,2 > > When I explore the source code of kernel (at vm_kern.c and vm_map.c), I > see that the panic can occur with the cases at below: > > * negative malloc size parameter > > * longer than free buffer respect to kmem_map min_offset and max_offset > values > > * try to allocate when the root entry of map is the rightmost entry of map > > * try to allocate bigger than map's max_free value > > I think the panic occurs at mbuf creation process when calling malloc() as > a result of couldn't be able to allocate memory; but I don't understand why > one of this panic case activating? The memory is almost empty but the > device is saying kmem_map small when using about 0.5GB memory purely. How > can i solve this panic problem? > > Thank you all for your time. > > -- Best Wishes, > > Tugrul Erdogan > > From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 26 11:53:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2FFAB653 for ; Fri, 26 Jul 2013 11:53:16 +0000 (UTC) (envelope-from feld@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 046B02460 for ; Fri, 26 Jul 2013 11:53:15 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B54AD20F43 for ; Fri, 26 Jul 2013 07:53:14 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Fri, 26 Jul 2013 07:53:14 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=8UOWk980zGY1QGZakySFkbLbfaQ=; b=dcj p3ZM740zx4lvPbvW+s9kolGhcd1466lAt7/AXHkfjpo0aIUny53J3VeW/f8y/PrX E23dS9R40Xy8/UaKeezpckDec316uSbvtSlIFjP/JCxNinNLGA+44/DJHWyLYnAg L0OF7zmnzBDfkXnaWFZSZxgR+Ege0tsDSJDCwCjI= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 9B78CB01D6C; Fri, 26 Jul 2013 07:53:14 -0400 (EDT) Message-Id: <1374839594.21160.1849239.4F1117A1@webmail.messagingengine.com> X-Sasl-Enc: GnHkoE2iMcCrXVO2OqoQTSdYNshRHcvI9n0RgE+sjpIp 1374839594 From: Mark Felder To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-23e62cd3 In-Reply-To: References: Subject: Re: panic: kmem_map too small at heavy packet traffic Date: Fri, 26 Jul 2013 06:53:14 -0500 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 11:53:16 -0000 I've been under the impression that synproxy was broken for quite some time, but I know there has been a lot of work on pf in HEAD so I can't be sure where it might stand there. Can anyone confirm/deny this? And not to discourage you, but the pf documentation does say "Routine use of this option is not recommended, however, as it breaks expected TCP protocol behavior when the server can't process the request..." However, panics are never good and hopefully someone can help you figure it out. From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 26 13:04:41 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 757C5455; Fri, 26 Jul 2013 13:04:41 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D76E92A3B; Fri, 26 Jul 2013 13:04:40 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id c13so1556935eek.31 for ; Fri, 26 Jul 2013 06:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; bh=HGPlcJD1Bf6ILb7GtRZLOyZlGJlzBEO+6rGDargYJgs=; b=rw/8+gLNVFoXudVUgm0A9uLIaLmAtNaTSqZPNlhjY9KxEdEkZ5HIsumYKYWeZC3BYa a+5vh8VhbV2tlmVyU2CdxhOPNq1YQwhTBlzi9D1pf+GEdaFifkrTjs12Cr/4viuRZM78 nsaE354bKJk/Xq57v1vLamG9UvWZWDM7vxWnJujQMdr02nAMj+yOrPitUpUDA2rns7BY IZpLNu+/zbI9x9rZ77j3O/5CMFoq2dHAbi95bm6yKmWDT+oChuy7C1UbB2dxmxBPtepb xemgSt2GWVQ4/Ja2SdlIkIgPyY9N4KEe+6wAOcOTRWqxw8dgsb1irESN6Pvq6D5LsrP/ MYdw== X-Received: by 10.15.33.132 with SMTP id c4mr47703145eev.12.1374843879085; Fri, 26 Jul 2013 06:04:39 -0700 (PDT) Received: from DOMYPC (78-2-147-88.adsl.net.t-com.hr. [78.2.147.88]) by mx.google.com with ESMTPSA id n42sm80897372eeh.15.2013.07.26.06.04.36 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Jul 2013 06:04:37 -0700 (PDT) Message-ID: <20130726.130442.843.4@DOMY-PC> From: rank1seeker@gmail.com To: "John Baldwin" Subject: Re: UFS related panic (daily <-> find) Date: Fri, 26 Jul 2013 15:04:42 +0200 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable In-Reply-To: <201307221329.47690.jhb@freebsd.org> References: <20130719.174511.786.3@DOMY-PC> <201307221329.47690.jhb@freebsd.org> X-Mailer: POP Peeper (3.8.1.0) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 13:04:41 -0000 > > I had 2 panics: (Both occured at 3 AM, so had to be daily task)=0D=0A> = > =0D=0A> > First (Jul 2 03:06:50 2013):=0D=0A> > --=0D=0A> > Fatal trap = 12: page fault while in kernel mode=0D=0A> > fault virtual address =3D = 0x19=0D=0A> > fault code =3D supervisor read, page not = present=0D=0A> > instruction pointer =3D 0x20:0xc06caf34=0D=0A> > = stack pointer =3D 0x28:0xe76248fc=0D=0A> > frame pointer = =3D 0x28:0xe7624930=0D=0A> > code segment =3D base 0x0, = limit 0xfffff, type 0x1b=0D=0A> > =3D DPL 0, pres = 1, def32 1, gran 1=0D=0A> > processor eflags =3D interrupt = enabled, resume, IOPL =3D 0=0D=0A> > current process =3D 76562 = (find)=0D=0A> > trap number =3D 12=0D=0A> > panic: page = fault=0D=0A> > Uptime: 23h0m41s=0D=0A> > Physical memory: 1014 MB=0D=0A> = > Dumping 186 MB: 171 155 139 123 107 91 75 59 43 27 11=0D=0A> > =0D=0A> = > #7 0xc06caf34 in cache_lookup_times (dvp=3D0xc784a990, = vpp=3D0xe7624ae8,=0D=0A> > cnp=3D0xe7624afc, tsp=3D0x0, ticksp=3D0x0) = at =0D=0A> /usr/src/sys/kern/vfs_cache.c:547=0D=0A> =0D=0A> Can you go up = to this frame and do 'l'?=0D=0A> =0D=0A> -- =0D=0A> John = Baldwin=0D=0A=0D=0A=0D=0ASure,=0D=0A=0D=0A---------=0D=0A(kgdb) up = 7=0D=0A#7 0xc06caf34 in cache_lookup_times (dvp=3D0xc784a990, = vpp=3D0xe7624ae8, cnp=3D0xe7624afc, tsp=3D0x0, ticksp=3D0x0) at = /usr/src/sys/kern/vfs_cache.c:547=0D=0A547 = numchecks++;=0D=0A---------=0D=0A(kgdb) l=0D=0A542 = }=0D=0A543=0D=0A544 hash =3D fnv_32_buf(cnp->cn_nameptr, = cnp->cn_namelen, FNV1_32_INIT);=0D=0A545 hash =3D = fnv_32_buf(&dvp, sizeof(dvp), hash);=0D=0A546 = LIST_FOREACH(ncp, (NCHHASH(hash)), nc_hash) {=0D=0A547 = numchecks++;=0D=0A548 if (ncp->nc_dvp =3D=3D dvp && = ncp->nc_nlen =3D=3D cnp->cn_namelen &&=0D=0A549 = !bcmp(nc_get_name(ncp), cnp->cn_nameptr, ncp->nc_nlen))=0D=0A550 = break;=0D=0A551 = }=0D=0A---------=0D=0A=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 26 14:57:59 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D786C994 for ; Fri, 26 Jul 2013 14:57:59 +0000 (UTC) (envelope-from SumiTomohiko@neko-daisuki.ddo.jp) Received: from mailout11.eonet.ne.jp (smtp-out01.eonet.ne.jp [IPv6:2001:ce8:0:603::48]) by mx1.freebsd.org (Postfix) with ESMTP id 7516E2FDD for ; Fri, 26 Jul 2013 14:57:59 +0000 (UTC) Received: from ae0000-mailauth12.eo.k-opti.ad.jp (mailauth01 [10.36.196.204]) by ae0000-mailout11.eo.k-opti.ad.jp (Postfix) with ESMTP id F355E127743 for ; Fri, 26 Jul 2013 23:57:56 +0900 (JST) Received: from ae0000-mailauth12.eo.k-opti.ad.jp (localhost.localdomain [127.0.0.1]) by ae0000-mailauth12.eo.k-opti.ad.jp (Postfix) with ESMTP id F1DB21B727C for ; Fri, 26 Jul 2013 23:57:56 +0900 (JST) Received: from herrenchiemsee.local (101-141-142-125f1.osk3.eonet.ne.jp [101.141.142.125]) by ae0000-mailauth12.eo.k-opti.ad.jp (Postfix) with ESMTP id E42523AE2D3 for ; Fri, 26 Jul 2013 23:57:56 +0900 (JST) Received: from linderhof.local (101-141-142-125f1.osk3.eonet.ne.jp [101.141.142.125]) by herrenchiemsee.local (Postfix) with ESMTPSA id AF23FF1144 for ; Fri, 26 Jul 2013 23:57:56 +0900 (JST) Received: by linderhof.local (Postfix, from userid 1001) id D62D21E4FC59; Fri, 26 Jul 2013 23:57:55 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by linderhof.local (Postfix) with ESMTP id C88AD1E4F325 for ; Fri, 26 Jul 2013 23:57:55 +0900 (JST) Date: Fri, 26 Jul 2013 23:57:55 +0900 (JST) From: Tomohiko Sumi X-X-Sender: tom@linderhof.local To: FreeBSD Hackers Mailing List Subject: Android applications for fsyscall/nexec Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 14:57:59 -0000 I report the current status of fsyscall/nexec. fsyscall[1] is a system to transfer system call requests over network. The goal of it is using FreeBSD applications at another machine (including non-FreeBSD machines) without any modifications of applications. nexec[2] is a system to make connection between a "master" and a "slave" of fsyscall. I developed Java version of fsyscall slave. This means that any Java platforms can use FreeBSD applications over network. Actually, I implemented some Android applications using fsyscall/nexec. One is nexec client demo for Android[3]. This is a simple application to try fsyscall/nexec. Another one is animator[4]. This is an application to make stop motion movie. It uses ffmpeg on FreeBSD to generate a movie. Finally, these two applications use one service, nexec client for Android[5]. This is a core service for fsyscall/nexec. It also manages file access for security. My one machine is ready for nexec server now. The above applications use this server (neko-daisuki.ddo.jp) by default. Anyone can try fsyscall/nexec. [1] http://neko-daisuki.ddo.jp/~SumiTomohiko/fsyscall/index.html [2] http://neko-daisuki.ddo.jp/~SumiTomohiko/nexec/index.html [3] http://neko-daisuki.ddo.jp/~SumiTomohiko/android-nexec-client-demo/index.html [4] http://neko-daisuki.ddo.jp/~SumiTomohiko/animator/index.html [5] http://neko-daisuki.ddo.jp/~SumiTomohiko/android-nexec-client/index.html -- Tomohiko Sumi SumiTomohiko@neko-daisuki.ddo.jp http://neko-daisuki.ddo.jp/~SumiTomohiko/index.html From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 26 18:17:00 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7D87DAF5 for ; Fri, 26 Jul 2013 18:17:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5102A29E0 for ; Fri, 26 Jul 2013 18:17:00 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 24EBBB926; Fri, 26 Jul 2013 14:16:59 -0400 (EDT) From: John Baldwin To: rank1seeker@gmail.com Subject: Re: UFS related panic (daily <-> find) Date: Fri, 26 Jul 2013 11:16:58 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130719.174511.786.3@DOMY-PC> <201307221329.47690.jhb@freebsd.org> <20130726.130442.843.4@DOMY-PC> In-Reply-To: <20130726.130442.843.4@DOMY-PC> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1250" Content-Transfer-Encoding: 7bit Message-Id: <201307261116.58638.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 26 Jul 2013 14:16:59 -0400 (EDT) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 18:17:00 -0000 On Friday, July 26, 2013 9:04:42 am rank1seeker@gmail.com wrote: > > > I had 2 panics: (Both occured at 3 AM, so had to be daily task) > > > > > > First (Jul 2 03:06:50 2013): > > > -- > > > Fatal trap 12: page fault while in kernel mode > > > fault virtual address = 0x19 > > > fault code = supervisor read, page not present > > > instruction pointer = 0x20:0xc06caf34 > > > stack pointer = 0x28:0xe76248fc > > > frame pointer = 0x28:0xe7624930 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1, def32 1, gran 1 > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > current process = 76562 (find) > > > trap number = 12 > > > panic: page fault > > > Uptime: 23h0m41s > > > Physical memory: 1014 MB > > > Dumping 186 MB: 171 155 139 123 107 91 75 59 43 27 11 > > > > > > #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990, vpp=0xe7624ae8, > > > cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at > > /usr/src/sys/kern/vfs_cache.c:547 > > > > Can you go up to this frame and do 'l'? > > > > -- > > John Baldwin > > > Sure, > > --------- > (kgdb) up 7 > #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990, vpp=0xe7624ae8, cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at /usr/src/sys/kern/vfs_cache.c:547 > 547 numchecks++; > --------- > (kgdb) l > 542 } > 543 > 544 hash = fnv_32_buf(cnp->cn_nameptr, cnp->cn_namelen, FNV1_32_INIT); > 545 hash = fnv_32_buf(&dvp, sizeof(dvp), hash); > 546 LIST_FOREACH(ncp, (NCHHASH(hash)), nc_hash) { > 547 numchecks++; > 548 if (ncp->nc_dvp == dvp && ncp->nc_nlen == cnp->cn_namelen && > 549 !bcmp(nc_get_name(ncp), cnp->cn_nameptr, ncp->nc_nlen)) > 550 break; > 551 } > --------- Hmm, 'p ncp' and 'p *ncp' at that frame perhaps? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 26 19:00:37 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A5F84D4F; Fri, 26 Jul 2013 19:00:37 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 13BE92BBD; Fri, 26 Jul 2013 19:00:36 +0000 (UTC) Received: by mail-ea0-f171.google.com with SMTP id n15so1732291ead.2 for ; Fri, 26 Jul 2013 12:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:subject:date:in-reply-to:references:x-mailer; bh=FO0YdeSqpgjoW7z4fA9C2O96fyzFJ9firTaIENkNLC0=; b=SgE12AWrvPbxeHBigi/TIjqJpWg2Ml+qoj7RvTyRsO0h4FWkH+YucIfuhW8edRb9I9 bxZtI6L1KzCr9f2MW06NorApTFRNWr2sQydZeJAgARo71l5XEHln7HZRjg+/1ToRAK2a 7WLd/nd7mxXJRgOPiW8kZlXqEtuxcvaTcrg93IzyWjVBnLhxz+TemUnssLYLe0RA2RJx jdPdVF/46hbD7All1TJT5L8v3n/Zxzero6gCbgj2LJJA/PI5SCfKEfOf2OLynYb24nBM 25hh0aG+2SpsL58LuE5LGLw271dhkUlb5ivh/dmjtsgQBQ5+VL1RCcp0tYQ9yfRU9ASk 3Qhw== X-Received: by 10.14.216.73 with SMTP id f49mr48231579eep.119.1374865235452; Fri, 26 Jul 2013 12:00:35 -0700 (PDT) Received: from DOMYPC (78-2-147-88.adsl.net.t-com.hr. [78.2.147.88]) by mx.google.com with ESMTPSA id m1sm82759768eex.17.2013.07.26.12.00.33 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Jul 2013 12:00:34 -0700 (PDT) Message-ID: <20130726.190033.811.1@DOMY-PC> From: rank1seeker@gmail.com To: "John Baldwin" Subject: Re: UFS related panic (daily <-> find) Date: Fri, 26 Jul 2013 21:00:33 +0200 In-Reply-To: <201307261116.58638.jhb@freebsd.org> References: <20130719.174511.786.3@DOMY-PC> <201307221329.47690.jhb@freebsd.org> <20130726.130442.843.4@DOMY-PC> <201307261116.58638.jhb@freebsd.org> X-Mailer: POP Peeper (3.8.1.0) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 19:00:37 -0000 > > > > I had 2 panics: (Both occured at 3 AM, so had to be daily task) > > > > > > > > First (Jul 2 03:06:50 2013): > > > > -- > > > > Fatal trap 12: page fault while in kernel mode > > > > fault virtual address = 0x19 > > > > fault code = supervisor read, page not present > > > > instruction pointer = 0x20:0xc06caf34 > > > > stack pointer = 0x28:0xe76248fc > > > > frame pointer = 0x28:0xe7624930 > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > = DPL 0, pres 1, def32 1, gran 1 > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > current process = 76562 (find) > > > > trap number = 12 > > > > panic: page fault > > > > Uptime: 23h0m41s > > > > Physical memory: 1014 MB > > > > Dumping 186 MB: 171 155 139 123 107 91 75 59 43 27 11 > > > > > > > > #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990, vpp=0xe7624ae8, > > > > cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at > > > /usr/src/sys/kern/vfs_cache.c:547 > > > > > > Can you go up to this frame and do 'l'? > > > > > > -- > > > John Baldwin > > > > > > Sure, > > > > --------- > > (kgdb) up 7 > > #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990, vpp=0xe7624ae8, cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at /usr/src/sys/kern/vfs_cache.c:547 > > 547 numchecks++; > > --------- > > (kgdb) l > > 542 } > > 543 > > 544 hash = fnv_32_buf(cnp->cn_nameptr, cnp->cn_namelen, FNV1_32_INIT); > > 545 hash = fnv_32_buf(&dvp, sizeof(dvp), hash); > > 546 LIST_FOREACH(ncp, (NCHHASH(hash)), nc_hash) { > > 547 numchecks++; > > 548 if (ncp->nc_dvp == dvp && ncp->nc_nlen == cnp->cn_namelen && > > 549 !bcmp(nc_get_name(ncp), cnp->cn_nameptr, ncp->nc_nlen)) > > 550 break; > > 551 } > > --------- > > Hmm, 'p ncp' and 'p *ncp' at that frame perhaps? > (kgdb) p ncp $1 = (struct namecache *) 0x1 (kgdb) p *ncp Cannot access memory at address 0x1 From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 26 20:14:19 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8E2342C4; Fri, 26 Jul 2013 20:14:19 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AE5AE2E4E; Fri, 26 Jul 2013 20:14:13 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r6QKE7PJ028334; Fri, 26 Jul 2013 15:14:07 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.7/8.14.7/Submit) id r6QKE7Fe028333; Fri, 26 Jul 2013 15:14:07 -0500 (CDT) (envelope-from brooks) Date: Fri, 26 Jul 2013 15:14:07 -0500 From: Brooks Davis To: hackers@freebsd.org Subject: CFR: improvments to cfi(4) flash driver Message-ID: <20130726201407.GF13659@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pql/uPZNXIm1JCle" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: marcel@freebsd.org, imp@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 20:14:19 -0000 --Pql/uPZNXIm1JCle Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've made a number of improvements to the write performance of the CFI flash driver. The patch below merges the remaining changes. I've only implemented buffered write on Intel flash as that's all I currently have access to. I'm looking for review and/or testing of these changes. http://people.freebsd.org/~brooks/patches/cfi.diff -- Brooks MFP4 217312, 222008, 222052, 222053, 222673, 231484, 231491 Rework the timeout code to use actual time rather than a DELAY() loop and to use both typical and maximum to allow logging of timeout failures. Also correct the erase timeout, it is specified in milliseconds not microseconds like the other timeouts. Do not invoke DELAY() between status queries as this adds significant latency which in turn reduced write performance substantially. Implement support for buffered writes (only enabled on Intel/Sharp parts for now). This yields an order of magnitude speedup on the 64MB Intel StrataFlash parts we use. When making a copy of the block to modify, also keep a clean copy around until we are ready to commit the block and use it to avoid unnecessary erases. In the non-buffer write case, also use it to avoid unnecessary writes when the block has not been erased. This yields a significant speedup when doing things like zeroing a block. Sponsored by: DARPA, AFRL diff -ru /home/bed22/p4/freebsd/src/sys/dev/cfi/cfi_bus_nexus.c ./cfi_bus_n= exus.c --- /home/bed22/p4/freebsd/src/sys/dev/cfi/cfi_bus_nexus.c 2013-04-29 20:40= :02.000000000 +0100 +++ ./cfi_bus_nexus.c 2013-07-26 20:36:34.000000000 +0100 @@ -4,6 +4,11 @@ * Copyright (c) 2009 Sam Leffler, Errno Consulting * All rights reserved. * + * Portions of this software were developed by SRI International and the + * University of Cambridge Computer Laboratory under DARPA/AFRL contract + * (FA8750-10-C-0237) ("CTSRD"), as part of the DARPA CRASH research + * programme. + * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: diff -ru /home/bed22/p4/freebsd/src/sys/dev/cfi/cfi_core.c ./cfi_core.c --- /home/bed22/p4/freebsd/src/sys/dev/cfi/cfi_core.c 2013-06-03 15:41:18.0= 00000000 +0100 +++ ./cfi_core.c 2013-07-26 20:40:32.000000000 +0100 @@ -1,7 +1,13 @@ /*- * Copyright (c) 2007, Juniper Networks, Inc. + * Copyright (c) 2012-2013, SRI International * All rights reserved. * + * Portions of this software were developed by SRI International and the + * University of Cambridge Computer Laboratory under DARPA/AFRL contract + * (FA8750-10-C-0237) ("CTSRD"), as part of the DARPA CRASH research + * programme. + * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: @@ -279,11 +285,31 @@ sc->sc_tag =3D rman_get_bustag(sc->sc_res); sc->sc_handle =3D rman_get_bushandle(sc->sc_res); =20 - /* Get time-out values for erase and write. */ - sc->sc_write_timeout =3D 1 << cfi_read_qry(sc, CFI_QRY_TTO_WRITE); - sc->sc_erase_timeout =3D 1 << cfi_read_qry(sc, CFI_QRY_TTO_ERASE); - sc->sc_write_timeout *=3D 1 << cfi_read_qry(sc, CFI_QRY_MTO_WRITE); - sc->sc_erase_timeout *=3D 1 << cfi_read_qry(sc, CFI_QRY_MTO_ERASE); + /* Get time-out values for erase, write, and buffer write. */ + sc->sc_typical_timeouts[CFI_TIMEOUT_ERASE] =3D + SBT_1MS * (1 << cfi_read_qry(sc, CFI_QRY_TTO_ERASE)); + sc->sc_max_timeouts[CFI_TIMEOUT_ERASE] =3D + sc->sc_typical_timeouts[CFI_TIMEOUT_ERASE] * + (1 << cfi_read_qry(sc, CFI_QRY_MTO_ERASE)); + + sc->sc_typical_timeouts[CFI_TIMEOUT_WRITE] =3D + SBT_1US * (1 << cfi_read_qry(sc, CFI_QRY_TTO_WRITE)); + sc->sc_max_timeouts[CFI_TIMEOUT_WRITE] =3D + sc->sc_typical_timeouts[CFI_TIMEOUT_WRITE] * + (1 << cfi_read_qry(sc, CFI_QRY_MTO_WRITE)); + + sc->sc_typical_timeouts[CFI_TIMEOUT_BUFWRITE] =3D + SBT_1US * (1 << cfi_read_qry(sc, CFI_QRY_TTO_BUFWRITE)); + sc->sc_max_timeouts[CFI_TIMEOUT_BUFWRITE] =3D + sc->sc_typical_timeouts[CFI_TIMEOUT_BUFWRITE] * + (1 << cfi_read_qry(sc, CFI_QRY_MTO_BUFWRITE)); + + /* Get the maximum size of a multibyte program */ + if (sc->sc_typical_timeouts[CFI_TIMEOUT_BUFWRITE] !=3D 0) + sc->sc_maxbuf =3D 1 << (cfi_read_qry(sc, CFI_QRY_MAXBUF) | + cfi_read_qry(sc, CFI_QRY_MAXBUF) << 8); + else + sc->sc_maxbuf =3D 0; =20 /* Get erase regions. */ sc->sc_regions =3D cfi_read_qry(sc, CFI_QRY_NREGIONS); @@ -351,18 +377,20 @@ } =20 static int -cfi_wait_ready(struct cfi_softc *sc, u_int ofs, u_int timeout) +cfi_wait_ready(struct cfi_softc *sc, u_int ofs, sbintime_t start, + enum cfi_wait_cmd cmd) { - int done, error; + int done, error, tto_exceeded; uint32_t st0 =3D 0, st =3D 0; + sbintime_t mend, now, tend; + + tend =3D start + sc->sc_typical_timeouts[cmd]; + mend =3D start + sc->sc_max_timeouts[cmd]; =20 done =3D 0; error =3D 0; - timeout *=3D 10; - while (!done && !error && timeout) { - DELAY(100); - timeout--; - + tto_exceeded =3D 0; + while (!done && !error) { switch (sc->sc_cmdset) { case CFI_VEND_INTEL_ECS: case CFI_VEND_INTEL_SCS: @@ -390,7 +418,25 @@ done =3D ((st & 0x40) =3D=3D (st0 & 0x40)) ? 1 : 0; break; } + + now =3D sbinuptime(); + if (tto_exceeded || now > tend) { + if (!tto_exceeded) + tto_exceeded =3D 1; + if (now > mend) { +#ifdef CFI_DEBUG_TIMEOUT + device_printf(sc->sc_dev, + "max timeout exceeded (cmd %d)", cmd); +#endif + break; + } + } } +#ifdef CFI_DEBUG_TIMEOUT + if (tto_exceeded) + device_printf(sc->sc_dev, + "typical timeout exceeded (cmd %d)", cmd); +#endif if (!done && !error) error =3D ETIMEDOUT; if (error) @@ -405,9 +451,12 @@ uint8_t *x8; uint16_t *x16; uint32_t *x32; - } ptr; + } ptr, cpyprt; register_t intr; - int error, i; + int error, i, neederase =3D 0; + uint32_t st; + u_int wlen; + sbintime_t start; =20 /* Intel flash must be unlocked before modification */ switch (sc->sc_cmdset) { @@ -419,31 +468,124 @@ break; } =20 - /* Erase the block. */ - switch (sc->sc_cmdset) { - case CFI_VEND_INTEL_ECS: - case CFI_VEND_INTEL_SCS: - cfi_write(sc, sc->sc_wrofs, CFI_BCS_BLOCK_ERASE); - cfi_write(sc, sc->sc_wrofs, CFI_BCS_CONFIRM); - break; - case CFI_VEND_AMD_SCS: - case CFI_VEND_AMD_ECS: - cfi_amd_write(sc, sc->sc_wrofs, AMD_ADDR_START, - CFI_AMD_ERASE_SECTOR); - cfi_amd_write(sc, sc->sc_wrofs, 0, CFI_AMD_BLOCK_ERASE); - break; - default: - /* Better safe than sorry... */ - return (ENODEV); - } - error =3D cfi_wait_ready(sc, sc->sc_wrofs, sc->sc_erase_timeout); - if (error) - goto out; + /* Check if an erase is required. */ + for (i =3D 0; i < sc->sc_wrbufsz; i++) + if ((sc->sc_wrbuf[i] & sc->sc_wrbufcpy[i]) !=3D sc->sc_wrbuf[i]) { + neederase =3D 1; + break; + } + + if (neederase) { + intr =3D intr_disable(); + start =3D sbinuptime(); + /* Erase the block. */ + switch (sc->sc_cmdset) { + case CFI_VEND_INTEL_ECS: + case CFI_VEND_INTEL_SCS: + cfi_write(sc, sc->sc_wrofs, CFI_BCS_BLOCK_ERASE); + cfi_write(sc, sc->sc_wrofs, CFI_BCS_CONFIRM); + break; + case CFI_VEND_AMD_SCS: + case CFI_VEND_AMD_ECS: + cfi_amd_write(sc, sc->sc_wrofs, AMD_ADDR_START, + CFI_AMD_ERASE_SECTOR); + cfi_amd_write(sc, sc->sc_wrofs, 0, CFI_AMD_BLOCK_ERASE); + break; + default: + /* Better safe than sorry... */ + intr_restore(intr); + return (ENODEV); + } + intr_restore(intr); + error =3D cfi_wait_ready(sc, sc->sc_wrofs, start,=20 + CFI_TIMEOUT_ERASE); + if (error) + goto out; + } else + error =3D 0; =20 - /* Write the block. */ + /* Write the block using a multibyte write if supported. */ ptr.x8 =3D sc->sc_wrbuf; + cpyprt.x8 =3D sc->sc_wrbufcpy; + if (sc->sc_maxbuf > sc->sc_width) { + switch (sc->sc_cmdset) { + case CFI_VEND_INTEL_ECS: + case CFI_VEND_INTEL_SCS: + for (i =3D 0; i < sc->sc_wrbufsz; i +=3D wlen) { + wlen =3D MIN(sc->sc_maxbuf, sc->sc_wrbufsz - i); + + intr =3D intr_disable(); + + start =3D sbinuptime(); + do { + cfi_write(sc, sc->sc_wrofs + i, + CFI_BCS_BUF_PROG_SETUP); + if (sbinuptime() > start + sc->sc_max_timeouts[CFI_TIMEOUT_BUFWRITE])= { + error =3D ETIMEDOUT; + goto out; + } + st =3D cfi_read(sc, sc->sc_wrofs + i); + } while (! (st & CFI_INTEL_STATUS_WSMS)); + + cfi_write(sc, sc->sc_wrofs + i, + (wlen / sc->sc_width) - 1); + switch (sc->sc_width) { + case 1: + bus_space_write_region_1(sc->sc_tag, + sc->sc_handle, sc->sc_wrofs + i, + ptr.x8 + i, wlen); + break; + case 2: + bus_space_write_region_2(sc->sc_tag, + sc->sc_handle, sc->sc_wrofs + i, + ptr.x16 + i / 2, wlen / 2); + break; + case 4: + bus_space_write_region_4(sc->sc_tag, + sc->sc_handle, sc->sc_wrofs + i, + ptr.x32 + i / 4, wlen / 4); + break; + } + + cfi_write(sc, sc->sc_wrofs + i, + CFI_BCS_CONFIRM); + + intr_restore(intr); + + error =3D cfi_wait_ready(sc, sc->sc_wrofs + i, + start, CFI_TIMEOUT_BUFWRITE); + if (error !=3D 0) + goto out; + } + goto out; + default: + /* Fall through to single word case */ + break; + } + + } + + /* Write the block one byte/word at a time. */ for (i =3D 0; i < sc->sc_wrbufsz; i +=3D sc->sc_width) { =20 + /* Avoid writing unless we are actually changing bits */ + if (!neederase) { + switch (sc->sc_width) { + case 1: + if(*(ptr.x8 + i) =3D=3D *(cpyprt.x8 + i)) + continue; + break; + case 2: + if(*(ptr.x16 + i / 2) =3D=3D *(cpyprt.x16 + i / 2)) + continue; + break; + case 4: + if(*(ptr.x32 + i / 4) =3D=3D *(cpyprt.x32 + i / 4)) + continue; + break; + } + } + /* * Make sure the command to start a write and the * actual write happens back-to-back without any @@ -451,6 +593,7 @@ */ intr =3D intr_disable(); =20 + start =3D sbinuptime(); switch (sc->sc_cmdset) { case CFI_VEND_INTEL_ECS: case CFI_VEND_INTEL_SCS: @@ -464,21 +607,22 @@ switch (sc->sc_width) { case 1: bus_space_write_1(sc->sc_tag, sc->sc_handle, - sc->sc_wrofs + i, *(ptr.x8)++); + sc->sc_wrofs + i, *(ptr.x8 + i)); break; case 2: bus_space_write_2(sc->sc_tag, sc->sc_handle, - sc->sc_wrofs + i, *(ptr.x16)++); + sc->sc_wrofs + i, *(ptr.x16 + i / 2)); break; case 4: bus_space_write_4(sc->sc_tag, sc->sc_handle, - sc->sc_wrofs + i, *(ptr.x32)++); + sc->sc_wrofs + i, *(ptr.x32 + i / 4)); break; } - + =09 intr_restore(intr); =20 - error =3D cfi_wait_ready(sc, sc->sc_wrofs, sc->sc_write_timeout); + error =3D cfi_wait_ready(sc, sc->sc_wrofs, start, + CFI_TIMEOUT_WRITE); if (error) goto out; } @@ -576,6 +720,7 @@ #ifdef CFI_ARMEDANDDANGEROUS register_t intr; int i, error; + sbintime_t start; #endif =20 if (sc->sc_cmdset !=3D CFI_VEND_INTEL_ECS) @@ -585,11 +730,12 @@ #ifdef CFI_ARMEDANDDANGEROUS for (i =3D 7; i >=3D 4; i--, id >>=3D 16) { intr =3D intr_disable(); + start =3D sbinuptime(); cfi_write(sc, 0, CFI_INTEL_PP_SETUP); cfi_put16(sc, CFI_INTEL_PR(i), id&0xffff); intr_restore(intr); - error =3D cfi_wait_ready(sc, CFI_BCS_READ_STATUS, - sc->sc_write_timeout); + error =3D cfi_wait_ready(sc, CFI_BCS_READ_STATUS, start, + CFI_TIMEOUT_WRITE); if (error) break; } @@ -629,6 +775,7 @@ #ifdef CFI_ARMEDANDDANGEROUS register_t intr; int error; + sbintime_t start; #endif if (sc->sc_cmdset !=3D CFI_VEND_INTEL_ECS) return EOPNOTSUPP; @@ -638,10 +785,12 @@ /* worthy of console msg */ device_printf(sc->sc_dev, "set PLR\n"); intr =3D intr_disable(); + binuptime(&start); cfi_write(sc, 0, CFI_INTEL_PP_SETUP); cfi_put16(sc, CFI_INTEL_PLR, 0xFFFD); intr_restore(intr); - error =3D cfi_wait_ready(sc, CFI_BCS_READ_STATUS, sc->sc_write_timeout); + error =3D cfi_wait_ready(sc, CFI_BCS_READ_STATUS, start, + CFI_TIMEOUT_WRITE); cfi_write(sc, 0, CFI_BCS_READ_ARRAY); return error; #else diff -ru /home/bed22/p4/freebsd/src/sys/dev/cfi/cfi_dev.c ./cfi_dev.c --- /home/bed22/p4/freebsd/src/sys/dev/cfi/cfi_dev.c 2012-11-11 22:15:34.00= 0000000 +0000 +++ ./cfi_dev.c 2013-07-26 20:36:34.000000000 +0100 @@ -1,7 +1,13 @@ /*- * Copyright (c) 2007, Juniper Networks, Inc. + * Copyright (c) 2012-2013, SRI International * All rights reserved. * + * Portions of this software were developed by SRI International and the + * University of Cambridge Computer Laboratory under DARPA/AFRL contract + * (FA8750-10-C-0237) ("CTSRD"), as part of the DARPA CRASH research + * programme. + * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: @@ -72,7 +78,8 @@ * Begin writing into a new block/sector. We read the sector into * memory and keep updating that, until we move into another sector * or the process stops writing. At that time we write the whole - * sector to flash (see cfi_block_finish). + * sector to flash (see cfi_block_finish). To avoid unneeded erase + * cycles, keep a pristine copy of the sector on hand. */ int cfi_block_start(struct cfi_softc *sc, u_int ofs) @@ -116,6 +123,8 @@ break; } } + sc->sc_wrbufcpy =3D malloc(sc->sc_wrbufsz, M_TEMP, M_WAITOK); + memcpy(sc->sc_wrbufcpy, sc->sc_wrbuf, sc->sc_wrbufsz); sc->sc_writing =3D 1; return (0); } @@ -131,6 +140,7 @@ =20 error =3D cfi_write_block(sc); free(sc->sc_wrbuf, M_TEMP); + free(sc->sc_wrbufcpy, M_TEMP); sc->sc_wrbuf =3D NULL; sc->sc_wrbufsz =3D 0; sc->sc_wrofs =3D 0; diff -ru /home/bed22/p4/freebsd/src/sys/dev/cfi/cfi_disk.c ./cfi_disk.c --- /home/bed22/p4/freebsd/src/sys/dev/cfi/cfi_disk.c 2013-06-18 19:57:42.0= 00000000 +0100 +++ ./cfi_disk.c 2013-07-26 20:36:34.000000000 +0100 @@ -1,7 +1,13 @@ /*- * Copyright (c) 2009 Sam Leffler, Errno Consulting + * Copyright (c) 2012-2013, SRI International * All rights reserved. * + * Portions of this software were developed by SRI International and the + * University of Cambridge Computer Laboratory under DARPA/AFRL contract + * (FA8750-10-C-0237) ("CTSRD"), as part of the DARPA CRASH research + * programme. + * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: diff -ru /home/bed22/p4/freebsd/src/sys/dev/cfi/cfi_reg.h ./cfi_reg.h --- /home/bed22/p4/freebsd/src/sys/dev/cfi/cfi_reg.h 2013-06-03 15:41:18.00= 0000000 +0100 +++ ./cfi_reg.h 2013-07-26 20:36:34.000000000 +0100 @@ -1,7 +1,13 @@ /*- * Copyright (c) 2007, Juniper Networks, Inc. + * Copyright (c) 2012-2013, SRI International * All rights reserved. * + * Portions of this software were developed by SRI International and the + * University of Cambridge Computer Laboratory under DARPA/AFRL contract + * (FA8750-10-C-0237) ("CTSRD"), as part of the DARPA CRASH research + * programme. + * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: @@ -44,8 +50,8 @@ u_char max_vcc; u_char min_vpp; u_char max_vpp; - u_char tto_byte_write; /* 2**n milliseconds. */ - u_char tto_buf_write; /* 2**n milliseconds. */ + u_char tto_byte_write; /* 2**n microseconds. */ + u_char tto_buf_write; /* 2**n microseconds. */ u_char tto_block_erase; /* 2**n milliseconds. */ u_char tto_chip_erase; /* 2**n milliseconds. */ u_char mto_byte_write; /* 2**n times typical t/o. */ @@ -70,12 +76,15 @@ #define CFI_QRY_VEND offsetof(struct cfi_qry, pri_vend) =20 #define CFI_QRY_TTO_WRITE offsetof(struct cfi_qry, tto_byte_write) +#define CFI_QRY_TTO_BUFWRITE offsetof(struct cfi_qry, tto_buf_write) #define CFI_QRY_TTO_ERASE offsetof(struct cfi_qry, tto_block_erase) #define CFI_QRY_MTO_WRITE offsetof(struct cfi_qry, mto_byte_write) +#define CFI_QRY_MTO_BUFWRITE offsetof(struct cfi_qry, mto_buf_write) #define CFI_QRY_MTO_ERASE offsetof(struct cfi_qry, mto_block_erase) =20 #define CFI_QRY_SIZE offsetof(struct cfi_qry, size) #define CFI_QRY_IFACE offsetof(struct cfi_qry, iface) +#define CFI_QRY_MAXBUF offsetof(struct cfi_qry, max_buf_write_size) #define CFI_QRY_NREGIONS offsetof(struct cfi_qry, nregions) #define CFI_QRY_REGION0 offsetof(struct cfi_qry, region) #define CFI_QRY_REGION(x) (CFI_QRY_REGION0 + (x) * 4) @@ -102,6 +111,7 @@ #define CFI_BCS_ERASE_SUSPEND 0xb0 #define CFI_BCS_ERASE_RESUME 0xd0 /* Equals CONFIRM */ #define CFI_BCS_CONFIRM 0xd0 +#define CFI_BCS_BUF_PROG_SETUP 0xe8 #define CFI_BCS_READ_ARRAY 0xff =20 /* Intel commands. */ diff -ru /home/bed22/p4/freebsd/src/sys/dev/cfi/cfi_var.h ./cfi_var.h --- /home/bed22/p4/freebsd/src/sys/dev/cfi/cfi_var.h 2012-11-11 22:15:34.00= 0000000 +0000 +++ ./cfi_var.h 2013-07-26 20:36:34.000000000 +0100 @@ -1,7 +1,13 @@ /*- * Copyright (c) 2007, Juniper Networks, Inc. + * Copyright (c) 2012-2013, SRI International * All rights reserved. * + * Portions of this software were developed by SRI International and the + * University of Cambridge Computer Laboratory under DARPA/AFRL contract + * (FA8750-10-C-0237) ("CTSRD"), as part of the DARPA CRASH research + * programme. + * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: @@ -32,6 +38,12 @@ #ifndef _DEV_CFI_VAR_H_ #define _DEV_CFI_VAR_H_ =20 +enum cfi_wait_cmd { + CFI_TIMEOUT_ERASE, + CFI_TIMEOUT_WRITE, + CFI_TIMEOUT_BUFWRITE +}; + struct cfi_region { u_int r_blocks; u_int r_blksz; @@ -51,13 +63,16 @@ struct cfi_region *sc_region; /* Array of region info. */ =20 u_int sc_cmdset; - u_int sc_erase_timeout; - u_int sc_write_timeout; + sbintime_t sc_typical_timeouts[3]; + sbintime_t sc_max_timeouts[3]; + + u_int sc_maxbuf; =20 struct cdev *sc_nod; struct proc *sc_opened; /* Process that has us opened. */ =20 u_char *sc_wrbuf; + u_char *sc_wrbufcpy; u_int sc_wrbufsz; u_int sc_wrofs; u_int sc_writing; --Pql/uPZNXIm1JCle Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFR8tiOXY6L6fI4GtQRAoPbAJ9VrfpXnRKjnV8tnfJi7fU6q5im5ACfSIuY xoYMK9+xfA/KnHNyaCwS6hY= =APjN -----END PGP SIGNATURE----- --Pql/uPZNXIm1JCle-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 26 20:20:34 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0D2B6408 for ; Fri, 26 Jul 2013 20:20:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D802E2E7F for ; Fri, 26 Jul 2013 20:20:33 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AF2B8B94C; Fri, 26 Jul 2013 16:20:32 -0400 (EDT) From: John Baldwin To: rank1seeker@gmail.com Subject: Re: UFS related panic (daily <-> find) Date: Fri, 26 Jul 2013 16:08:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130719.174511.786.3@DOMY-PC> <201307261116.58638.jhb@freebsd.org> <20130726.190033.811.1@DOMY-PC> In-Reply-To: <20130726.190033.811.1@DOMY-PC> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201307261608.11556.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 26 Jul 2013 16:20:32 -0400 (EDT) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 20:20:34 -0000 On Friday, July 26, 2013 3:00:33 pm rank1seeker@gmail.com wrote: > > > > > I had 2 panics: (Both occured at 3 AM, so had to be daily task) > > > > > > > > > > First (Jul 2 03:06:50 2013): > > > > > -- > > > > > Fatal trap 12: page fault while in kernel mode > > > > > fault virtual address = 0x19 > > > > > fault code = supervisor read, page not present > > > > > instruction pointer = 0x20:0xc06caf34 > > > > > stack pointer = 0x28:0xe76248fc > > > > > frame pointer = 0x28:0xe7624930 > > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > > = DPL 0, pres 1, def32 1, gran 1 > > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > > current process = 76562 (find) > > > > > trap number = 12 > > > > > panic: page fault > > > > > Uptime: 23h0m41s > > > > > Physical memory: 1014 MB > > > > > Dumping 186 MB: 171 155 139 123 107 91 75 59 43 27 11 > > > > > > > > > > #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990, > vpp=0xe7624ae8, > > > > > cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at > > > > /usr/src/sys/kern/vfs_cache.c:547 > > > > > > > > Can you go up to this frame and do 'l'? > > > > > > > > -- > > > > John Baldwin > > > > > > > > > Sure, > > > > > > --------- > > > (kgdb) up 7 > > > #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990, vpp=0xe7624ae8, > cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at /usr/src/sys/kern/vfs_cache.c:547 > > > 547 numchecks++; > > > --------- > > > (kgdb) l > > > 542 } > > > 543 > > > 544 hash = fnv_32_buf(cnp->cn_nameptr, cnp->cn_namelen, > FNV1_32_INIT); > > > 545 hash = fnv_32_buf(&dvp, sizeof(dvp), hash); > > > 546 LIST_FOREACH(ncp, (NCHHASH(hash)), nc_hash) { > > > 547 numchecks++; > > > 548 if (ncp->nc_dvp == dvp && ncp->nc_nlen == > cnp->cn_namelen && > > > 549 !bcmp(nc_get_name(ncp), cnp->cn_nameptr, > ncp->nc_nlen)) > > > 550 break; > > > 551 } > > > --------- > > > > Hmm, 'p ncp' and 'p *ncp' at that frame perhaps? > > > > (kgdb) p ncp > $1 = (struct namecache *) 0x1 > (kgdb) p *ncp > Cannot access memory at address 0x1 Interesting. Maybe look at NCHHASH(hash) (you'll have to expand the macro manually) and see if the head node is corrupted or walk the list to find the corrupted node. Given that it is a single bit error, there is a chance this is a RAM problem. If it is in the hash table head entry then that would always be at the same physical address for the same kernel I think. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 26 21:21:47 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7B025407 for ; Fri, 26 Jul 2013 21:21:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 12C1D20F0 for ; Fri, 26 Jul 2013 21:21:46 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u57so2261981wes.23 for ; Fri, 26 Jul 2013 14:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=NYYdf4RxOUr9R3lDz6dlZfzrrWsgf3bKCgCWiUX0AQ4=; b=Q7DtmHMa8Jbj91bhs3Cm+I9amu2QsYqvPlRirwm5XsD2tORP7n/qN/acg+CDBY3RCw 27uAbuwCJD21t/IHoOoAmOT6eCpUfFKd/QXXYQLWvDOslSNwMEPx2GvWCo/GHC87TXTK sVLCOoRp5mvEuINhwAWOirmkaxGyKCz5wzuLHz1/B8azER40yOAdVeGY4reVHuKFT+Ul m4oLvceV3aDWz85md00SeCmQl4GxNVOhb5kEED2jHUzwP6Uk+E8KN/opOQXZ/lD7xEwB xOhxZ98KWb/x00LzmfN9329+hxscLcWjf03xEpHnD3rwq7fmnBoqGnQU3q2KzroUbhgW usFg== MIME-Version: 1.0 X-Received: by 10.180.160.165 with SMTP id xl5mr274833wib.46.1374873705398; Fri, 26 Jul 2013 14:21:45 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Fri, 26 Jul 2013 14:21:45 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Jul 2013 14:21:45 -0700 X-Google-Sender-Auth: tehrJYogm9Wl93XjyziGseJncpI Message-ID: Subject: Re: panic: kmem_map too small at heavy packet traffic From: Adrian Chadd To: Tugrul Erdogan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 21:21:47 -0000 Hi Have you filed a PR? This should get fixed. Also, being -ve is a problem. Is the value really negative? Is it wrapping badly? -adrian On 25 July 2013 07:57, Tugrul Erdogan wrote: > howdy all, > > At my work, I am using 10.0-CURRENT on Intel(R) Xeon(R) E5620 with 16GB > ram. I am taking > > "panic: kmem_malloc(-548663296): kmem_map too small: 539459584 total allocated" > > message with configuration below: > > [root@ ~]# sysctl vm.kmem_size_min vm.kmem_size_max vm.kmem_size > vm.kmem_size_scale > vm.kmem_size_min: 0 > vm.kmem_size_max: 329853485875 > vm.kmem_size: 16686845952 > vm.kmem_size_scale: 1 > [root@ ~]# sysctl hw.physmem hw.usermem hw.realmem > hw.physmem: 17151787008 > hw.usermem: 8282652672 > hw.realmem: 18253611008 > [root@ ~]# sysctl hw.pagesize hw.pagesizes hw.availpages > hw.pagesize: 4096 > hw.pagesizes: 4096 2097152 0 > hw.availpages: 4187448 > > > When I compare vmstat and netstat output of boot time result and > subsequent result, the major difference are seemed at: > > pf_temp 0 0K - 79309736 128 | pf_temp 1077640 134705K - 84330076 128 > > and after the panic at the core dump file the major vmstat difference is: > > temp 110 15K - 76212305 16,32,64,128,256 | temp 117 6742215K - 655115 > 16,32,64,128,2 > > When I explore the source code of kernel (at vm_kern.c and vm_map.c), I see > that the panic can occur with the cases at below: > > * negative malloc size parameter > > * longer than free buffer respect to kmem_map min_offset and max_offset > values > > * try to allocate when the root entry of map is the rightmost entry of map > > * try to allocate bigger than map's max_free value > > I think the panic occurs at mbuf creation process when calling malloc() as > a result of couldn't be able to allocate memory; but I don't understand why > one of this panic case activating? The memory is almost empty but the > device is saying kmem_map small when using about 0.5GB memory purely. How > can i solve this panic problem? > > Thank you all for your time. > > -- Best Wishes, > > Tugrul Erdogan > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 27 07:26:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9CCB8B6C; Sat, 27 Jul 2013 07:26:28 +0000 (UTC) (envelope-from h.tugrul.erdogan@gmail.com) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4A1572AB4; Sat, 27 Jul 2013 07:26:28 +0000 (UTC) Received: by mail-ve0-f169.google.com with SMTP id db10so1875768veb.0 for ; Sat, 27 Jul 2013 00:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qjMn6rwM5tSDWPx43Fy3n0bTYEQqYixhsJtvM6MfRLU=; b=etoI/ZuDcDKS1dJyYqRXAZFCNhfmNwYlaFx8q6gC6unRhlEAXVe65xcWPk6o30SG/z Z9nRnGRguTma9/W4W3bLCM5norWfL7OJa8A91Apb1K03oIBiXSzGqqDnbjFV1tVOJoU3 0rGmxJ8S94mgBBHGf510aGWt+wVMoFibHOM3c7nfZWdmY378fytF+ZCwnM7i2M6X7dHe AzXRJAaChNH1Aw/HYFPQnLe3QYeLKJikVrJ1zDjqz+ypN0dIfZgpNE64/pl7v20g0HKZ myxFVQcP0zjP0ZeIELGANzkgS8mOzZVOV9PLqXlpwxLRdHncKBiQqrg63pKRilTsqyKK CgAQ== MIME-Version: 1.0 X-Received: by 10.220.175.84 with SMTP id w20mr5080220vcz.84.1374909987371; Sat, 27 Jul 2013 00:26:27 -0700 (PDT) Received: by 10.58.54.103 with HTTP; Sat, 27 Jul 2013 00:26:27 -0700 (PDT) In-Reply-To: References: Date: Sat, 27 Jul 2013 10:26:27 +0300 Message-ID: Subject: Re: panic: kmem_map too small at heavy packet traffic From: Tugrul Erdogan To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 07:26:28 -0000 I have just pilled a PR. The negative written value is directly malloc's size parameter (in fact after some page size alignment enlargements operation). This parameter has been defined as "unsigned long" but printing with "%ld" as signed long. So if the size is very very big (more than 2^63 at amd64), the signed printing can remark the first bit of size as sign bit then write the - sign. But I think the size can not be so big, for this reason you are right, there must be a problem (the size parameter can come as negative or the enlargement functions can destroy the size parameter). On Sat, Jul 27, 2013 at 12:21 AM, Adrian Chadd wrote: > Hi > > Have you filed a PR? This should get fixed. > > Also, being -ve is a problem. Is the value really negative? Is it > wrapping badly? > > > > -adrian > > On 25 July 2013 07:57, Tugrul Erdogan wrote: > > howdy all, > > > > At my work, I am using 10.0-CURRENT on Intel(R) Xeon(R) E5620 with 16GB > > ram. I am taking > > > > "panic: kmem_malloc(-548663296): kmem_map too small: 539459584 total > allocated" > > > > message with configuration below: > > > > [root@ ~]# sysctl vm.kmem_size_min vm.kmem_size_max vm.kmem_size > > vm.kmem_size_scale > > vm.kmem_size_min: 0 > > vm.kmem_size_max: 329853485875 > > vm.kmem_size: 16686845952 > > vm.kmem_size_scale: 1 > > [root@ ~]# sysctl hw.physmem hw.usermem hw.realmem > > hw.physmem: 17151787008 > > hw.usermem: 8282652672 > > hw.realmem: 18253611008 > > [root@ ~]# sysctl hw.pagesize hw.pagesizes hw.availpages > > hw.pagesize: 4096 > > hw.pagesizes: 4096 2097152 0 > > hw.availpages: 4187448 > > > > > > When I compare vmstat and netstat output of boot time result and > > subsequent result, the major difference are seemed at: > > > > pf_temp 0 0K - 79309736 128 | pf_temp 1077640 134705K - 84330076 128 > > > > and after the panic at the core dump file the major vmstat difference is: > > > > temp 110 15K - 76212305 16,32,64,128,256 | temp 117 6742215K - 655115 > > 16,32,64,128,2 > > > > When I explore the source code of kernel (at vm_kern.c and vm_map.c), I > see > > that the panic can occur with the cases at below: > > > > * negative malloc size parameter > > > > * longer than free buffer respect to kmem_map min_offset and max_offset > > values > > > > * try to allocate when the root entry of map is the rightmost entry of > map > > > > * try to allocate bigger than map's max_free value > > > > I think the panic occurs at mbuf creation process when calling malloc() > as > > a result of couldn't be able to allocate memory; but I don't understand > why > > one of this panic case activating? The memory is almost empty but the > > device is saying kmem_map small when using about 0.5GB memory purely. How > > can i solve this panic problem? > > > > Thank you all for your time. > > > > -- Best Wishes, > > > > Tugrul Erdogan > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 27 21:58:45 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9D8056D2 for ; Sat, 27 Jul 2013 21:58:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3334E26D1 for ; Sat, 27 Jul 2013 21:58:45 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id n11so725875wgh.21 for ; Sat, 27 Jul 2013 14:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=W7aKrGCF0ZQpkjL88yza3nV2H/XHKWuAz7+EglS5aSM=; b=0TG9oMwNNjwLMH0CP2SFip/svlJui8AaYtmEHtCse78G68+v2VMsOfFUN6UqSpcOzV dytU6gLX6N07gUkeh37HYd463v7Mob4tKcBWDIiPwd5XA2WUnROaoA566cyqiDeitQC6 1bzM059mygR6KA3Yg0r2xSmIIMq3gvmtfH3Ilwq4c82+NW/BMtSBruJA5JP0LbbZ0rfC oJB0+Il6Hmm/80RumYfCOTegsOCdHukxTVBePsATpV9Tnu0VwzvhkbbU/ACGTA0GiOui +gUNjMcLDRA2Cl/IOYDeHW9invyMK20tQVGIE/AV6We+CW/+GfAomfFEQ6hIuprOnXj3 xZUg== MIME-Version: 1.0 X-Received: by 10.180.160.165 with SMTP id xl5mr2804796wib.46.1374962323567; Sat, 27 Jul 2013 14:58:43 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Sat, 27 Jul 2013 14:58:43 -0700 (PDT) In-Reply-To: References: Date: Sat, 27 Jul 2013 14:58:43 -0700 X-Google-Sender-Auth: eoMhM13PsAevteljV6GylRvma5o Message-ID: Subject: Re: panic: kmem_map too small at heavy packet traffic From: Adrian Chadd To: Tugrul Erdogan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 21:58:45 -0000 Cool, what's the PR number? It sounds like something is odd. Email -current with the PR details (number, how you reproduce it, etc) and let's see if we can get one of the VM/UMA gurus to look into it. Thanks, -adrian On 27 July 2013 00:26, Tugrul Erdogan wrote: > I have just pilled a PR. > > The negative written value is directly malloc's size parameter (in fact > after some page size alignment enlargements operation). This parameter has > been defined as "unsigned long" but printing with "%ld" as signed long. So > if the size is very very big (more than 2^63 at amd64), the signed printing > can remark the first bit of size as sign bit then write the - sign. But I > think the size can not be so big, for this reason you are right, there must > be a > problem (the size parameter can come as negative or the enlargement > functions can destroy the size parameter). > > > On Sat, Jul 27, 2013 at 12:21 AM, Adrian Chadd wrote: >> >> Hi >> >> Have you filed a PR? This should get fixed. >> >> Also, being -ve is a problem. Is the value really negative? Is it >> wrapping badly? >> >> >> >> -adrian >> >> On 25 July 2013 07:57, Tugrul Erdogan wrote: >> > howdy all, >> > >> > At my work, I am using 10.0-CURRENT on Intel(R) Xeon(R) E5620 with 16GB >> > ram. I am taking >> > >> > "panic: kmem_malloc(-548663296): kmem_map too small: 539459584 total >> > allocated" >> > >> > message with configuration below: >> > >> > [root@ ~]# sysctl vm.kmem_size_min vm.kmem_size_max vm.kmem_size >> > vm.kmem_size_scale >> > vm.kmem_size_min: 0 >> > vm.kmem_size_max: 329853485875 >> > vm.kmem_size: 16686845952 >> > vm.kmem_size_scale: 1 >> > [root@ ~]# sysctl hw.physmem hw.usermem hw.realmem >> > hw.physmem: 17151787008 >> > hw.usermem: 8282652672 >> > hw.realmem: 18253611008 >> > [root@ ~]# sysctl hw.pagesize hw.pagesizes hw.availpages >> > hw.pagesize: 4096 >> > hw.pagesizes: 4096 2097152 0 >> > hw.availpages: 4187448 >> > >> > >> > When I compare vmstat and netstat output of boot time result and >> > subsequent result, the major difference are seemed at: >> > >> > pf_temp 0 0K - 79309736 128 | pf_temp 1077640 134705K - 84330076 128 >> > >> > and after the panic at the core dump file the major vmstat difference >> > is: >> > >> > temp 110 15K - 76212305 16,32,64,128,256 | temp 117 6742215K - 655115 >> > 16,32,64,128,2 >> > >> > When I explore the source code of kernel (at vm_kern.c and vm_map.c), I >> > see >> > that the panic can occur with the cases at below: >> > >> > * negative malloc size parameter >> > >> > * longer than free buffer respect to kmem_map min_offset and max_offset >> > values >> > >> > * try to allocate when the root entry of map is the rightmost entry of >> > map >> > >> > * try to allocate bigger than map's max_free value >> > >> > I think the panic occurs at mbuf creation process when calling malloc() >> > as >> > a result of couldn't be able to allocate memory; but I don't understand >> > why >> > one of this panic case activating? The memory is almost empty but the >> > device is saying kmem_map small when using about 0.5GB memory purely. >> > How >> > can i solve this panic problem? >> > >> > Thank you all for your time. >> > >> > -- Best Wishes, >> > >> > Tugrul Erdogan >> > _______________________________________________ >> > freebsd-hackers@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> > To unsubscribe, send any mail to >> > "freebsd-hackers-unsubscribe@freebsd.org" > >