6.1-RC2: strange kernel panic!
Kris Kennaway
kris at obsecurity.org
Tue May 2 20:10:56 UTC 2006
On Tue, May 02, 2006 at 08:59:38PM +0200, No at SPAM@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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20060502/405dd98d/attachment.pgp
More information about the freebsd-questions
mailing list