From owner-freebsd-net Wed Nov 20 11:57:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 090F437B401; Wed, 20 Nov 2002 11:57:41 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7B2943E9C; Wed, 20 Nov 2002 11:57:39 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id gAKJvbBF054682; Wed, 20 Nov 2002 14:57:37 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 20 Nov 2002 14:57:37 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Petri Helenius Cc: David Schultz , freebsd-questions@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: panic: kmem_map too small In-Reply-To: <3DDBDE2B.6050407@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 20 Nov 2002, Petri Helenius wrote: > David Schultz wrote: > > >Thus spake Petri Helenius : > > > > > >>I seem to get kmem_map too small panics when using large buffers with > >>bpf. Is there a tunable I should be increasing? > >> > >> > > > >Yes, increase KVA_PAGES in your kernel config. > > > > > I put in KVA_PAGES=1024 > with following results on next boot: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; lapic.id = 06000000 > fault virtual address = 0x1 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc01efc88 > stack pointer = 0x10:0xdf0ccbcc > frame pointer = 0x10:0xdf0ccbf0 > 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 = 15 (swi1: net) > trap number lastlog: Permission denied > > Removing the option and recompiling kernel from the same sources makes > it work fine. Looks like some network stack code is responding poorly to malloc() failing (which it can). Any chance you can generate a stack trace for this by compiling DDB into your kernel, then using the trace command to generate the trace? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message