Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Oct 1999 15:02:07 +0300 (EEST)
From:      Adrian Penisoara <ady@warpnet.ro>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG
Subject:   Re: [Patches avail?] Re: MMAP() in STABLE/CURRENT ... 
Message-ID:  <Pine.BSF.4.10.9910051443270.1079-100000@ady.warpnet.ro>
In-Reply-To: <199910041929.MAA68462@apollo.backplane.com>

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

On Mon, 4 Oct 1999, Matthew Dillon wrote:

> : Excuse my intrusion, but could you be so kind to tell me whether you had
> :the time to build patches for these MMAP-related freezes ? If not could
> :you recommend me some workarounds ?
> :
> : I have a -stable production server that keeps (solidly) blocking pretty
> :often (I don't get over 3 days uptimes). If you need details just let me
> :know.
> :
> :> 					-Matt
> :> 					Matthew Dillon 
> :> 					<dillon@backplane.com>
> : Thanks,
> : Ady (@warpnet.ro)
> 
>     Well, your lockups may or may not be related to the remaining mmap
>     problems.  They could be related to the swap fragmentation problems
>     in stable, or they could be related to something else entirely.  In
>     order to determine the cause of your lockup problems, some additional
>     information is necessary.  The easiest way to get the information is
>     to enable DDB and kernel core dumps so you can panic the machine from

 The problem is that the machine is completely locked, I can't get into
the debugger with CTR-ALT-ESC; no panics so there are no coredumps
catched. Any advise ? Could you escape in the debugger when you were hit
by these bugs ?

>     the console and get a core.  Once you have the core
>     'cd /var/crash; ps -M vmcore.X -N kernel.X' (where X is the latest
>     dump number) can be used to determine what the processes were doing
>     when they locked up.
> 
>     The two most common VM-related lockups in -stable are:
> 
>     (1) swap metadata fragmentation due to paging in the face of large 
> 	running processes (system runs out of KVM), and

 I have: squid (20Mb), nntpcached (17Mb SIZE, 1Mb RES), apache, named,
MFS, a few PPP processes and the rest of the standard menu.

> 
>     (2) write()ing the mmap'd area of one file descriptor to another.
> 

 OK, how about some workarounds, I can't wait anylonger for this to be
fixed, my situation got critical. Should I downgrade to 3.1-RELEASE (that
hadn't exhibit this way) or can I dare a 4.0-CURRENT (are these problems
present in -current too ?) ?

> 					-Matt
> 					Matthew Dillon 
> 					<dillon@backplane.com>
> 

 Thanks,
 Ady (@warpnet.ro)



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9910051443270.1079-100000>