From root@bone.bone.servebeer.com  Sat Aug  7 21:46:23 2004
Return-Path: <root@bone.bone.servebeer.com>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 1FF8016A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Sat,  7 Aug 2004 21:46:23 +0000 (GMT)
Received: from bone.bone.servebeer.com (81-178-89-169.dsl.pipex.com [81.178.89.169])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 84A7A43D53
	for <FreeBSD-gnats-submit@freebsd.org>; Sat,  7 Aug 2004 21:46:22 +0000 (GMT)
	(envelope-from root@bone.bone.servebeer.com)
Received: by bone.bone.servebeer.com (Postfix, from userid 0)
	id D2191312E7; Sat,  7 Aug 2004 22:45:26 +0100 (BST)
Message-Id: <20040807214526.D2191312E7@bone.bone.servebeer.com>
Date: Sat,  7 Aug 2004 22:45:26 +0100 (BST)
From: Markie <mrboo@bone.bone.servebeer.com>
Reply-To: Markie <mrboo@bone.bone.servebeer.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: Kernel Panic 5.2.1-R and -CURRENT. kmem_alloc(4096)	
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         70148
>Category:       kern
>Synopsis:       [panic] Kernel Panic 5.2.1-R and -CURRENT. kmem_alloc(4096)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Aug 07 21:50:24 GMT 2004
>Closed-Date:    Sat Jul 30 01:03:41 GMT 2005
>Last-Modified:  Sat Jul 30 01:03:41 GMT 2005
>Originator:     Markie
>Release:        FreeBSD 5.2-CURRENT i386
>Organization:
>Environment:
System: FreeBSD bone.bone.servebeer.com 5.2-CURRENT FreeBSD 5.2-CURRENT #3: Thu Jul 1 18:43:06 BST 2004 mrboo@bone.bone.servebeer.com:/usr/obj/usr/src/sys/BONE i386


	
>Description:
	Machine panics with the following message:
panic: kmem_malloc(4096): kmem_map too small: 41299968 total allocated

syncing disks, buffers remaining... 1134 1134 1134 1133 1133 1133 1133 1133 1133 1133 1133 1133 1133 1133 1133 1133 1133 1133 1133 1133 1133 1133 1133
giving up on 812 buffers
Uptime: 45d13h45m51s
Dumping 95MB
 16 32 48 64 80

it wasn't a debugging kernel but from the backtrace of the dump from 5.2.1-R, for what it is worth, I got:

(kgdb) bt
#0  0xc04dd1fb in doadump ()
#1  0xc04dd87f in boot ()
#2  0xc04ddc18 in panic ()
#3  0xc05f39a0 in kmem_malloc ()
#4  0xc0605687 in page_alloc ()
#5  0xc06052f3 in slab_zalloc ()
#6  0xc0606646 in uma_zone_slab ()
#7  0xc060689f in uma_zalloc_bucket ()
#8  0xc06064c8 in uma_zalloc_arg ()
#9  0xc04d13ac in malloc ()
#10 0xc04b9e35 in fdcopy ()
#11 0xc04c5a35 in fork1 ()
#12 0xc04c504b in fork ()
#13 0xc063a0c0 in syscall ()
#14 0xc062adfd in Xint0x80_syscall ()
---Can't read userspace from dump, or kernel process---

I realise this was a problem with large md disks, but I don't run any of that kind of stuff so I figure perhaps I have a different problem here. I have also seen mention of large amount of RAM causing this, but the machine only has 96MB of RAM.

I can't be sure it's related, but the last time it panic'd I got quite a few of these messages in /var/log/messages just before:

Jul 30 01:19:57 bone kernel: arpresolve: can't allocate llinfo for xxx.xxx.xxx.xxxrt
Jul 30 01:19:58 bone kernel: arplookup xxx.xxx.xxx.xxx failed: could not allocate llinfo
Jul 30 01:19:58 bone kernel: arpresolve: can't allocate llinfo for xxx.xxx.xxx.xxxrt
Jul 30 01:19:58 bone kernel: arplookup xxx.xxx.xxx.xxx failed: could not allocate llinfo
Jul 30 01:19:58 bone kernel: arpresolve: can't allocate llinfo for xxx.xxx.xxx.xxxrt
Jul 30 01:19:59 bone kernel: arplookup xxx.xxx.xxx.xxx failed: could not allocate llinfo
Jul 30 01:19:59 bone kernel: arpresolve: can't allocate llinfo for xxx.xxx.xxx.xxxrt
Jul 30 01:20:00 bone kernel: arplookup xxx.xxx.xxx.xxx failed: could not allocate llinfo

Thanks...


>How-To-Repeat:
	Leave my machine running for more than about 20 days. 
>Fix:

	


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: glebius 
State-Changed-When: Sat Dec 11 22:15:53 GMT 2004 
State-Changed-Why:  
I remember this problem. If I do not mistake it was fixed 
shortly after being intoroduced. 

Does the problem reappear on recent CURRENT kernels or 
on RELENG_4? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=70148 
State-Changed-From-To: feedback->closed 
State-Changed-By: kris 
State-Changed-When: Sat Jul 30 01:03:28 GMT 2005 
State-Changed-Why:  
Feedback timeout 

http://www.freebsd.org/cgi/query-pr.cgi?pr=70148 
>Unformatted:
