From owner-freebsd-questions@FreeBSD.ORG Thu Jan 26 11:29:20 2006 Return-Path: X-Original-To: questions@freebsd.org Delivered-To: freebsd-questions@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3654816A420 for ; Thu, 26 Jan 2006 11:29:20 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id C60C043D45 for ; Thu, 26 Jan 2006 11:29:19 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so343141nzo for ; Thu, 26 Jan 2006 03:29:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Qy4Ash1ZxPt0PO6JktRa5OEFXCul9ejj4CszyRcRXuNDuSZT0vXGkOlyA7Bw9LroFMvbsIe52EwBh9XOgo8AABOp54GIhURqaH8WpPTLCMR5+mtQ+Upox79/OkM0STSGea53HOEfqV6clwSIf/yrZkOOJqiUbOB1TfWDV1Bsk+4= Received: by 10.37.20.29 with SMTP id x29mr1443732nzi; Thu, 26 Jan 2006 03:29:19 -0800 (PST) Received: by 10.37.20.67 with HTTP; Thu, 26 Jan 2006 03:29:19 -0800 (PST) Message-ID: Date: Thu, 26 Jan 2006 14:29:19 +0300 From: Andrew Pantyukhin To: FreeBSD Questions MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: Buffer space and socket syscall tracing X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 11:29:20 -0000 I've stumbled upon the infamous "No buffer space available" problem (with thousands of netgraph nodes). I'm wondering if there's a really comprehensive way to debug it. I know that it's probably a matter of some sysctl, but I've googled and tuned for days - and I now feel that there must be another way. Truss and ktrace both say that the error is generated when a socket syscall is made. Is there a way to trace inside the syscall and find the very particular reason for this? I know that it might not be of any use to me as I'm not any kind of kernel hacker, but I want to give it a shot. Thanks