Date: Sat, 7 Aug 2004 22:45:26 +0100 (BST) From: Markie <mrboo@bone.bone.servebeer.com> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/70148: Kernel Panic 5.2.1-R and -CURRENT. kmem_alloc(4096) Message-ID: <20040807214526.D2191312E7@bone.bone.servebeer.com> Resent-Message-ID: <200408072150.i77LoPCa098196@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 70148 >Category: kern >Synopsis: Kernel Panic 5.2.1-R and -CURRENT. kmem_alloc(4096) >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Aug 07 21:50:24 GMT 2004 >Closed-Date: >Last-Modified: >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: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040807214526.D2191312E7>