Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 May 2006 16:10:54 -0400
From:      Kris Kennaway <kris@obsecurity.org>
To:        "No@SPAM@mgEDV.net" <nospam@mgedv.net>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: 6.1-RC2: strange kernel panic!
Message-ID:  <20060502201054.GA93912@xor.obsecurity.org>
In-Reply-To: <002e01c66e1a$8fd083d0$dededede@avalon.lan>
References:  <20060502174604.GA91314@xor.obsecurity.org> <002e01c66e1a$8fd083d0$dededede@avalon.lan>

next in thread | previous in thread | raw e-mail | index | archive | help

--wac7ysb48OaltWcw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 02, 2006 at 08:59:38PM +0200, No@SPAM@mgEDV.net wrote:
> =20
> > 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=3D524288000      #500MB
> > You may need to increase it further.
>=20
> 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 ;-)
>=20
> our current settings are (default in GENERIC):
> vm.kmem_size: 335544320
> vm.kmem_size_max: 335544320
>=20
> the compilation system uses a 350MB swap-based memory-disk for compilatio=
n,
> the whole disks are encrypted using GELI (AES256). network traffic is low
> (only ssh commandline stuff, no huge transfers).
>=20
> 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=3Dsame)
> g_vfs_done():md0[WRITE(offset=3D346742784, length=3D6144)]error =3D 28
> g_vfs_done():md0[WRITE(offset=3D346750976, length=3D8192)]error =3D 28
> g_vfs_done():md0[WRITE(offset=3D346761216, length=3D6144)]error =3D 28
> g_vfs_done():md0[WRITE(offset=3D346767360, length=3D6144)]error =3D 28
> g_vfs_done():md0[WRITE(offset=3D346773504, length=3D6144)]error =3D 28

This is suspicious:

#define ENOSPC          28              /* No space left on device */

Are you sure you are using swap backing and not malloc?

Kris
--wac7ysb48OaltWcw
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)

iD8DBQFEV7zOWry0BWjoQKURAhTfAKDg4SjZCyQeVB75g2p/lbbhPWuGjACgyClM
AzNmC4ZJ+3NxU0KYbns3YZ4=
=0TGW
-----END PGP SIGNATURE-----

--wac7ysb48OaltWcw--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060502201054.GA93912>