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