RE: 6.1-RC2: strange kernel panic!
Don't you think you should test it instead of guessing? :-) I suggested it because it *is* a possibility (that is why I have it in my kernel). yes, but doesn't it make sense to find memory consuming things before adding more? btw. how can we check for such things? Are you sure you are using swap backing and not malloc? nope, i'm not sure if it was that, but -M was passed to mdmfs, so malloc(9) was used. we changed the code to swap-based, let's see if that fixes our problem. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.1-RC2: strange kernel panic!
On Wed, May 03, 2006 at 11:55:26AM +0200, [EMAIL PROTECTED]@mgEDV.net wrote: Don't you think you should test it instead of guessing? :-) I suggested it because it *is* a possibility (that is why I have it in my kernel). yes, but doesn't it make sense to find memory consuming things before adding more? btw. how can we check for such things? Are you sure you are using swap backing and not malloc? nope, i'm not sure if it was that, but -M was passed to mdmfs, so malloc(9) was used. we changed the code to swap-based, let's see if that fixes our problem. Since you were using malloc backing that is what used up all your kernel memory. Increasing memory per my suggestion would have fixed it. Chances are you don't want to use malloc backing anyway though, because it's slower (unless you're swapping). Kris pgplZzr0kvIPo.pgp Description: PGP signature
RE: 6.1-RC2: strange kernel panic! [SOLVED]
original error: panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated kernel panic issue seems to be solved by changing our memory disk from malloc(9) backed to a swap-backed disk. thx 4 helpin', guys! and yes, i could have tested it because this was already in the archives (shame on me) ;-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.1-RC2: strange kernel panic! [SOLVED]
On Wed, May 03, 2006 at 09:09:41PM +0200, [EMAIL PROTECTED]@mgEDV.net wrote: original error: panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated kernel panic issue seems to be solved by changing our memory disk from malloc(9) backed to a swap-backed disk. thx 4 helpin', guys! and yes, i could have tested it because this was already in the archives (shame on me) ;-) Great, it's nice when problems are resolved :) Kris pgppqRHtO1XQn.pgp Description: PGP signature
Re: 6.1-RC2: strange kernel panic!
On Tue, May 02, 2006 at 07:34:58PM +0200, [EMAIL PROTECTED]@mgEDV.net wrote: hi together! this is the 4th time the server died since last week (and the 1st time we catched the error!). it happened during an du -sk . of some large directory structure. panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated any ideas on this? this system should go live soon, so we definitely need to fix this! Your kernel ran out of memory. Either you are using a workload that is too heavy for your current settings, or there is a memory leak somewhere in a kernel subsystem you are using. Try to increase VM_KMEM_SIZE_MAX in your kernel, e.g. options VM_KMEM_SIZE_MAX=524288000 #500MB You may need to increase it further. Kris pgpJ0NLcfNKa2.pgp Description: PGP signature
RE: 6.1-RC2: strange kernel panic!
Your kernel ran out of memory. Either you are using a workload that is too heavy for your current settings, or there is a memory leak somewhere in a kernel subsystem you are using. Try to increase VM_KMEM_SIZE_MAX in your kernel, e.g. options VM_KMEM_SIZE_MAX=524288000 #500MB You may need to increase it further. i'm not sure, but probably this does not solve our problem. this system is used as a compilation host only (currently) and therefore there are no permanently running things like databases, huge daemons, etc... only ssh and syslog is up in userland. so the main question to me is, where the memory goes on this server, and how i can prevent this type of leak. (and even maybe help you fixin' it ;-) our current settings are (default in GENERIC): vm.kmem_size: 335544320 vm.kmem_size_max: 335544320 the compilation system uses a 350MB swap-based memory-disk for compilation, the whole disks are encrypted using GELI (AES256). network traffic is low (only ssh commandline stuff, no huge transfers). when i issued the du -sk the panic occurred. 5min ago, the system panic'd again, this time some more was logged: (originally, there have been 200 of these messages, numbers change, error=same) g_vfs_done():md0[WRITE(offset=346742784, length=6144)]error = 28 g_vfs_done():md0[WRITE(offset=346750976, length=8192)]error = 28 g_vfs_done():md0[WRITE(offset=346761216, length=6144)]error = 28 g_vfs_done():md0[WRITE(offset=346767360, length=6144)]error = 28 g_vfs_done():md0[WRITE(offset=346773504, length=6144)]error = 28 this time the panic occurred while transferring data from the hdd's to the md-device: panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated Uptime: 1h13m18s is there any way (which is suitable for a non-c-guru like me) how i can at least monitor, which statements cause the memory leaks? givin' it more memory could only raise the uptime, because at this time there are no permanently running processes except the os and ssh. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.1-RC2: strange kernel panic!
On Tue, May 02, 2006 at 08:59:38PM +0200, [EMAIL PROTECTED]@mgEDV.net wrote: Your kernel ran out of memory. Either you are using a workload that is too heavy for your current settings, or there is a memory leak somewhere in a kernel subsystem you are using. Try to increase VM_KMEM_SIZE_MAX in your kernel, e.g. options VM_KMEM_SIZE_MAX=524288000 #500MB You may need to increase it further. i'm not sure, but probably this does not solve our problem. Don't you think you should test it instead of guessing? :-) I suggested it because it *is* a possibility (that is why I have it in my kernel). this system is used as a compilation host only (currently) and therefore there are no permanently running things like databases, huge daemons, etc... only ssh and syslog is up in userland. so the main question to me is, where the memory goes on this server, and how i can prevent this type of leak. (and even maybe help you fixin' it ;-) our current settings are (default in GENERIC): vm.kmem_size: 335544320 vm.kmem_size_max: 335544320 the compilation system uses a 350MB swap-based memory-disk for compilation, the whole disks are encrypted using GELI (AES256). network traffic is low (only ssh commandline stuff, no huge transfers). when i issued the du -sk the panic occurred. Could be to do with GELI, I don't know about memory requirements. 5min ago, the system panic'd again, this time some more was logged: (originally, there have been 200 of these messages, numbers change, error=same) g_vfs_done():md0[WRITE(offset=346742784, length=6144)]error = 28 g_vfs_done():md0[WRITE(offset=346750976, length=8192)]error = 28 g_vfs_done():md0[WRITE(offset=346761216, length=6144)]error = 28 g_vfs_done():md0[WRITE(offset=346767360, length=6144)]error = 28 g_vfs_done():md0[WRITE(offset=346773504, length=6144)]error = 28 This is suspicious: #define ENOSPC 28 /* No space left on device */ Are you sure you are using swap backing and not malloc? Kris pgplfoAV2n5lE.pgp Description: PGP signature
