search for: kmem_map

...some tunable that I need to/can increase for this? A backtrace of the crash, if that shows anything: #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 #1 0xb714e4f3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:316 #2 0xb714e965 in panic (fmt=0xb72635e0 "kmem_malloc(%ld): kmem_map too small: %ld total allocated") at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xb71fccd7 in kmem_malloc (map=0xb729d100, size=16384, flags=2) at /usr/src/sys/vm/vm_kern.c:329 #4 0xb7149c5f in malloc (size=16384, type=0xb7287c60, flags=2) at /usr/src/sys/kern/kern_malloc.c:198 #5 0xb71ec113 i...

We have 10 SuperMicro PDSMi+ 5015M-MTs that are panic'ing every few days. This started shortly after upgrade from 6.2-RELEASE to 6.3-RELEASE with freebsd-update. Other than switching to a debugging kernel, a little sysctl tuning, and patching with freebsd-update, they are stock. The debugging kernel was built from source that is also being patched with freebsd-update. These systems are

...stem at that time, and brought the database back up. Everything seemed normal until this morning, where the database had become unresponsive again. Fortunately, I was able to grab some system statistics before the shell and console went AWOL. The only finding that I thought was suspicious were the kmem_map numbers: vm.kmem_map_free: 655360 vm.kmem_map_size: 17141383168 It's something like 0.004% free. I haven't been able to find much documentation on what to expect here, but I don't see anything like that for other databases that I've monitored. It is possible that kmem_map can be...

Guys, I've heard about some absurd RAM requirements for 9.1, has anybody tested it? e.g. http://forums.freebsd.org/showthread.php?t=36314 -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-1-minimal-ram-requirements-tp5771583.html Sent from the freebsd-stable mailing list archive at Nabble.com.

Andre, Are you going to have time to MFC things from -current for auto-tuning -stable before 9.2? I fear (maybe unnecessarily?) that we are about to ship yet another release that can't do basic 10gigE when sufficient memory exists. If you don't have time, then let me know and I'll see what I can do. -- Alfred Perlstein VP Software Engineering, iXsystems

...28 g_vfs_done():md0[WRITE(offset=1753202688, length=81920)]error = 28 g_vfs_done():md0[WRITE(offset=1191755776, length=131072)]error = 28 g_vfs_done():md0[WRITE(offset=1191886848, length=131072)]error = 28 g_vfs_done():md0[WRITE(offset=1192017920, length=131072)]error = 28 panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated cpuid = 1 KDB: enter: panic [thread pid 15139 tid 100160 ] Stopped at kdb_enter_why+0x3a: movl $0,kdb_why db> db> bt Tracing pid 15139 tid 100160 td 0xc7a85af0 kdb_enter_why(3231417278,3231417278,3231555983,3911968708,1,...) at kdb_enter_why+5...

...entry = next; 2176 } 2177 return (KERN_SUCCESS); 2178 } (kgdb) up #12 0xc025b161 in vm_map_remove (map=0xe8b3e040, start=0, end=3217031168) at /usr/src/sys/vm/vm_map.c:2199 2199 result = vm_map_delete(map, start, end); (kgdb) list 2194 if (map == kmem_map || map == mb_map) 2195 s = splvm(); 2196 2197 vm_map_lock(map); 2198 VM_MAP_RANGE_CHECK(map, start, end); 2199 result = vm_map_delete(map, start, end); 2200 vm_map_unlock(map); 2201 2202 if (map == kmem_map || map == mb_map)...

...Things are going very well with the tests, with the glaring exception of the following crash: While doing some significant disk operations: du, deleting a different part of the tree and finally running "sync" the machine locked hard with the following errors: panic: kmem_malloc(4096): kmem_map too small: 230162432 total allocated mp_lock = 03000001; cpuid = 3; lapic.id = 07000000 boot() called on cpu#3 Then "Synching disks" but no futher output is printed, nor is any further progress made. This machine was installed off of 4.8-release and was rebuilt under -stable as of april...

Hi. Just migrated to zfs on opensolaris. I copied data to the server using rsync and got this message: Oct 10 17:24:04 zetta ^Mpanic[cpu1]/thread=ffffff0007f1bc80: Oct 10 17:24:04 zetta genunix: [ID 683410 kern.notice] BAD TRAP: type=e (#pf Page fault) rp=ffffff0007f1b640 addr=fffffffecd873000 Oct 10 17:24:04 zetta unix: [ID 100000 kern.notice] Oct 10 17:24:04 zetta unix: [ID 839527 kern.notice]