Date: Mon, 24 Jun 2002 14:33:30 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Patrick Thomas <root@utility.clubscholarship.com> Cc: Nielsen <nielsen@memberwebs.com>, <hackers@FreeBSD.ORG>, Terry Lambert <tlambert2@mindspring.com> Subject: Re: (jail) problem and a (possible) solution ? Message-ID: <200206242133.g5OLXUht097591@apollo.backplane.com> References: <20020624124558.T68572-100000@utility.clubscholarship.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:questions:
:
:1) How do I give you an entire `ps` output from DDB ? Is there a way to
:output it to a floppy or something ? Or are you suggesting to copy down
:by hand ~1000 lines of ps output ?
If you have a couple of machines you can use a null-modem cable and
make the target machine's console the serial port by adding the
following line to the target machine's /boot/loader.conf:
console="comconsole"
(note: DDB will occur on the serial port now, not the main system
console). Then on the machine you connected the serial port you can
'tip com1' (I think). If you don't have a com1 in /etc/remote you can
add one:
com1:dv=/dev/cuaa0:br#9600:pa=none:
In anycase, this way the console will wind up on the serial port
and you can leave yourself tipped in with a big window and then cut
and paste when it drops into DDB> and you do the ps.
The other thing you want to do is to make sure all your kernel builds
are -g builds, which you can do by adding the following line to
/usr/src/sys/i386/conf/<YOURKERNEL> (I'm assuming from prior messages
that you are familiar with building kernels):
makeoptions DEBUG=-g
I also recommend:
options ALT_BREAK_TO_DEBUGGER
This will produce a kernel.debug as well as a kernel binary (only
'kernel' is installed, but kernel.debug will remain sitting in the
compile dir). ALT_BREAK_TO_DEBUGGER allows you to break into DDB>
via the serial console by using <CR> ~ ^B (return, tilde, control-B)
from your 'tip'.
Finally, make sure the swap partition is large enough to hold main
memory so the kernel dumps core, and use the 'dumpdev' option in
/etc/rc.conf to set the dump device. For example:
dumpdev="/dev/da0s1b"
:2) Any other suggestions as to what it is - if it doesn't look like KVA,
:and I reduced my swap from 2gig to 256megs, and I reduced maxusers from
:512 to 256 ... basically I have a perfectly healthy machine that crashes
:for no reason ?
:
:All of your help is greatly appreciated. It's just so frustrating to have
:it halt every day for no apparent reason - as you saw from the `top`
:output just as it halted the other day , the load is trivial.
:
:--PT
I don't know but hopefully a full PS will give us a better window into
the problem.
Oh yah, you can also play with different memory configurations simply
by setting a physical memory limit (<= actual physical ram in the box)
in /boot/loader.conf, like this:
hw.physmem="256m"
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206242133.g5OLXUht097591>