From owner-freebsd-current@FreeBSD.ORG Thu Aug 5 10:50:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78C7816A4CE for ; Thu, 5 Aug 2004 10:50:53 +0000 (GMT) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD84E43D1D for ; Thu, 5 Aug 2004 10:50:52 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received-SPF: pass (eva.fit.vutbr.cz: domain of xdivac02@eva.fit.vutbr.cz designates 127.0.0.1 as permitted sender) receiver=eva.fit.vutbr.cz; client_ip=127.0.0.1; envelope-from=xdivac02@eva.fit.vutbr.cz; Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (8.12.11/8.12.11) with ESMTP id i75AommV028377 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 5 Aug 2004 12:50:48 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.12.11/8.12.5/Submit) id i75Aom9E028376; Thu, 5 Aug 2004 12:50:48 +0200 (CEST) Date: Thu, 5 Aug 2004 12:50:48 +0200 From: Divacky Roman To: Max Laier Message-ID: <20040805105048.GA28144@stud.fit.vutbr.cz> References: <20040804125640.GA78633@stud.fit.vutbr.cz> <20040804130530.GA78973@stud.fit.vutbr.cz> <200408042003.07356.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408042003.07356.max@love2party.net> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: freebsd-current@freebsd.org cc: Dan Cojocar Subject: Re: problems with altq X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2004 10:50:53 -0000 On Wed, Aug 04, 2004 at 08:03:00PM +0200, Max Laier wrote: > On Wednesday 04 August 2004 15:05, Divacky Roman wrote: > > struct pf_altq *altq, *a; > > > > if (pa->ticket != ticket_altqs_inactive) { > > error = EBUSY; > > break; > > } > > altq = pool_get(&pf_altq_pl, PR_NOWAIT); > > ^^^^^^^^^^ > > shouldnt this be initalized to NULL? at least its not nice to have it > > uninitalized... > > hum? > $ cd /usr/src/sys/contrib/pf/net && grep pf_altq_pl * > <...> > pf_ioctl.c: pf_state_pl = pf_altq_pl = pf_pooladdr_pl = NULL; > pf_ioctl.c: UMA_DESTROY(pf_altq_pl); > pf_ioctl.c: UMA_CREATE(pf_altq_pl, struct pf_altq, "pfaltqpl"); > <...> > > Or what are you thinking about? pf/net/pf_ioctl.c:2032 and below hm... I got it wrong. I looked at it again and I changed type with variable name ;( hysteria.sk/~neologism/NEOLOGISM is my kernel config hysteria.sk/~neologism/pf.conf is my whole pf config I am compiling kernel with -Os (I know its not supported) I'll try with plain -O btw: why does the malloc has to be NOWAIT? > Just like Dan Cojocar said in his reply, I can't reproduce your problem > here :-\ I can provide you any information you'll ask for > > On Wed, Aug 04, 2004 at 02:56:40PM +0200, Divacky Roman wrote: > > > I am getting this > > > pfctl: DIOCADDALTQ: Cannot allocate memory > > > if I try to enable altq on pf configured as > > > > > > altq on $ext_if bandwidth 256Kb cbq queue { ssh_i web other} > > > queue ssh_i bandwidth 25% cbq(borrow red) > > > queue web bandwidth 25% cbq(borrow red) > > > queue other bandwidth 50% cbq(borrow default red) > > > > > > > > > without that "red" it works ok... > > Now that is strange as it makes no difference in the DIOCADDALTQ call path > whether you use RED or not. Might it be possible that you really are short on > (kernel) memory? vm.kvm_free: 562032640 vm.kvm_size: 1073737728 witten ~# vmstat procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad0 ad1 in sy cs us sy id 1 1 0 124936 189072 10 0 0 0 8 0 0 0 903 1010 1733 2 2 96 witten ~# /etc/rc.d/pf restart Disabling pf. pf disabled Enabling pf. pfctl: DIOCADDALTQ: Cannot allocate memory pf enabled witten ~# if this is what I think it is I should have enough kernel memory, shouldnt I? roman