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" >