NetBSD Problem Report #24715

Received: (qmail 12444 invoked by uid 605); 9 Mar 2004 12:35:07 -0000
Message-Id: <20040309123503.BB38B1D1A0@otaku.Xtrmntr.org>
Date: Tue,  9 Mar 2004 13:35:03 +0100 (CET)
From: Lubomir Sedlacik <salo@Xtrmntr.org>
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: salo@Xtrmntr.org
To: gnats-bugs@gnats.netbsd.org
Subject: system can stuck with no available ram when using swap on cgd(4) 
X-Send-Pr-Version: 3.95

>Number:         24715
>Category:       kern
>Synopsis:       system can stuck with no available ram when using swap on cgd(4)
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    elric
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 09 12:36:00 +0000 2004
>Closed-Date:    Tue Mar 30 17:17:52 +0000 2004
>Last-Modified:  Tue Mar 30 17:17:52 +0000 2004
>Originator:     Lubomir Sedlacik
>Release:        NetBSD 1.6ZI
>Organization:
>Environment:
Architecture: i386
Machine: i386
>Description:
System using swap on a cgd(4) device could stuck when it runs out of free
memory but there is still plenty of swap space available.  the problem seems
to be that cgd(4) doesn't have enough memory to decrypt/encrypt swap pages.

i was able to unfreeze the system for a moment by killing processes from ddb
(when i was lucky enough and was able to get into ddb) but never to fully
recover.  the issue is repeatable.

Roland Dowdeswell is aware of this issue, i filled the PR so it won't be
forgotten.

>How-To-Repeat:
use swap on cgd(4), make the machine use all the available ram, observe it
hang.
>Fix:
N/A
use memory pools?
>Release-Note:
>Audit-Trail:

From: "Roland C. Dowdeswell" <elric@imrryr.org>
To: salo@Xtrmntr.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/24715: system can stuck with no available ram when using swap on cgd(4) 
Date: Tue, 09 Mar 2004 10:01:41 -0500

 On 1078835703 seconds since the Beginning of the UNIX epoch
 Lubomir Sedlacik wrote:
 >

 >>Fix:
 >N/A
 >use memory pools?

 We are running out of memory and we need some to flush pages.  The
 fix will be:

 	1.  use the BUFQ infrastucture, like ccd(4), etc.,
 	2.  put a low ater mark on cgd_cbufpool,
 	3.  allocate some memory that we keep for ourselves for
 	    the encrypted data of one maximal sized request,
 	4.  if we cannot allocate memory when we are trying to
 	    write a buffer then put it on the queue,
 	5.  when our iodone is called, we will check to see if
 	    there are any requests on the queue and try to start
 	    them up.

 We need to do (2) and (3) because they make the guarantee that we
 can always make forward progress even in memory starvation situations
 because we will always be able to have at least one transaction
 outstanding.  (5) should guarantee that we will continue to try to
 make progress even if no new reads/writes are initiated.

 I've been thinking that the correct place to do all of this logic
 is probably in dksubr.c (and making cgdstart() capable of returning
 a ``no'' answer.)

 --
     Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/
Responsible-Changed-From-To: kern-bug-people->elric 
Responsible-Changed-By: elric 
Responsible-Changed-When: Tue Mar 16 20:28:30 EST 2004 
Responsible-Changed-Why:  
This is mine, I should claim it. 
State-Changed-From-To: open->feedback 
State-Changed-By: elric 
State-Changed-When: Sat Mar 27 18:23:44 EST 2004 
State-Changed-Why:  
Addressed by: 
$ cvs ci cgd.c cgdvar.h dksubr.c dkvar.h 
Checking in cgd.c; 
/cvsroot/src/sys/dev/cgd.c,v  <--  cgd.c 
new revision: 1.16; previous revision: 1.15 
done 
Checking in cgdvar.h; 
/cvsroot/src/sys/dev/cgdvar.h,v  <--  cgdvar.h 
new revision: 1.2; previous revision: 1.1 
done 
Checking in dksubr.c; 
/cvsroot/src/sys/dev/dksubr.c,v  <--  dksubr.c 
new revision: 1.11; previous revision: 1.10 
done 
Checking in dkvar.h; 
/cvsroot/src/sys/dev/dkvar.h,v  <--  dkvar.h 
new revision: 1.4; previous revision: 1.3 
done 


Responsible-Changed-From-To: elric->salo 
Responsible-Changed-By: elric 
Responsible-Changed-When: Sat Mar 27 18:23:44 EST 2004 
Responsible-Changed-Why:  
Because that is the flow of bugs. 
Responsible-Changed-From-To: salo->elric 
Responsible-Changed-By: salo 
Responsible-Changed-When: Sat Mar 27 23:59:26 UTC 2004 
Responsible-Changed-Why:  
*boing* 

From: Lubomir Sedlacik <salo@Xtrmntr.org>
To: gnats-bugs@gnats.netbsd.org
Cc:  
Subject: Re: kern/24715
Date: Tue, 30 Mar 2004 19:16:31 +0200

 hi,

 i can confirm that my machne is stable with these patches in.  the
 interactive responsiveness is dramatically deteriorated when it drains
 memory but system doesn't crash anymore (running simultaneously "cvs
 update" on pkgsrc, src, few firefox windows, xmms, terminals, ...).
 thanks!


 regards,

 -- 
 -- Lubomir Sedlacik <salo@Xtrmntr.org>                   --
 --                  <salo@silcnet.org>                   --
State-Changed-From-To: feedback->closed 
State-Changed-By: elric 
State-Changed-When: Tue Mar 30 12:17:39 EST 2004 
State-Changed-Why:  
Verified. 
>Unformatted:

Home	PR Database Search