NetBSD Problem Report #40027
From bouyer@antioche.eu.org Tue Nov 25 20:14:59 2008
Return-Path: <bouyer@antioche.eu.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by narn.NetBSD.org (Postfix) with ESMTP id 1083C63BD2D
for <gnats-bugs@gnats.NetBSD.org>; Tue, 25 Nov 2008 20:14:59 +0000 (UTC)
Message-Id: <200811252014.mAPKEsJb007691@rochebonne.antioche.eu.org>
Date: Tue, 25 Nov 2008 21:14:54 +0100 (CET)
From: Manuel Bouyer <bouyer@antioche.eu.org>
Reply-To: bouyer@antioche.eu.org
To: gnats-bugs@gnats.NetBSD.org
Subject: pagedaemon loops on memory shortage
X-Send-Pr-Version: 3.95
>Number: 40027
>Category: kern
>Synopsis: pagedaemon loops on memory shortage
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: ad
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Nov 25 20:15:00 +0000 2008
>Closed-Date: Mon Dec 29 12:45:57 +0000 2008
>Last-Modified: Mon Dec 29 12:45:57 +0000 2008
>Originator: Manuel Bouyer
>Release: NetBSD 5.99.3
>Organization:
>Environment:
System: NetBSD NetBSD 5.99.3 (XEN3PAE_DOMU) #13: Tue Nov 25 16:22:41 CET 2008 bouyer@rock:/dsk/l1/misc/bouyer/tmp/i386/obj/dsk/l1/misc/bouyer/current/src/sys/arch/i386/compile/XEN3PAE_DOMU i386
Architecture: i386
Machine: i386
This also affect 5.0_BETA as of today.
>Description:
test box: i386 with 512M RAM and 128 or 256M swap.
If a user program eats all available ram+swap, the pagedaemon will
eventually enter a loop where it eats 100% of the CPU without doing
anything, though there is freeable memory (in the case below, there are
inactive pages, and pages dedicated to executable or file cache that
could be recycled in this case).
There is no disk activity, and CPU is 100% busy in system.
Here's some collected info from ddb, and snapshots of 'top -s1' and
'systat vm -w1' windows.
ddb entered by cnmagic
Stopped in pid 0.24 (system) at netbsd:breakpoint+0x4: popl %ebp
db> sh uvm
Current UVM status:
pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12
127451 VM pages: 77010 active, 37610 inactive, 1584 wired, 4 free
pages 90929 anon, 23202 file, 576 exec
freemin=256, free-target=341, wired-max=42483
faults=1568252, traps=1506580, intrs=590339, ctxswitch=1541450
softint=465451, syscalls=2806949, swapins=110, swapouts=125
fault counts:
noram=37088, noanon=6, pgwait=2, pgrele=0
ok relocks(total)=5158(5161), anget(retrys)=150374(4059), amapcopy=61630
neighbor anon/obj pg=9019/67148, gets(lock/unlock)=19444/1102
cases: anon=111886, anoncow=4180, obj=17398, prcopy=2043, przero=1001038
daemon and swap counts:
woke=64202, revs=39057, scans=1702660, obscans=575273, anscans=990925
busy=0, freed=799033, reactivate=2580, deactivate=1648405
pageouts=163024, pending=215160, nswget=1367
nswapdev=1, swpgavail=32767
swpages=32767, swpginuse=32767, swpgonly=32763, paging=0
db>
ps /l shows that 0.24 is the pagedaemon
top:
load averages: 2.74, 1.89, 0.98 up 0 days, 0:14 20:22:35
22 processes: 4 runnable, 17 sleeping, 1 on CPU
CPU states: 0.0% user, 0.0% nice, 100% system, 0.0% interrupt, 0.0% idle
Memory: 300M Act, 147M Inact, 6336K Wired, 2304K Exec, 90M File, 20K Free
Swap: 128M Total, 128M Used, 4K Free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
470 root 85 0 752K 1184K RUN 0:05 2.85% 2.83% tar
490 root 39 0 748K 323M RUN 0:01 0.82% 0.73% hang
0 root 126 0 0K 15M pgdaemon 2:12 0.00% 0.00% [system]
systat:
3 users Load 3.63 2.16 1.10 Tue Nov 25 20:22:54
Proc:r d s w Csw Trp Sys Int Sof Flt PAGING SWAPPING
3 7 1 607 30 13 161 107 30 in out in out
ops 4 1 1
97.9% Sy 0.0% Us 0.0% Ni 0.0% In 2.1% Id pages 4
| | | | | | | | | | |
================================================= forks
fkppw
memory totals (in kB) 161 Interrupts fksvm
real virtual free vcpu0 xencons pwait
Active 307940 439008 16 153 vcpu0 clock relck
All 509788 640856 16 vcpu0 xenbus rlkok
6 vcpu0 xbd0 noram
Namei Sys-cache Proc-cache vcpu0 xbd1 ndcpy
Calls hits % hits % 2 vcpu0 xennet0 fltcp
17 17 100 zfod
cow
Disks: xbd0 xbd1 md0 256 fmin
seeks 341 ftarg
xfers 6 itarg
bytes 71K 1594 wired
%busy 0.5 4 pdfre
Eventually the memory-hungry program will be killed after some time, or
the box will die completely with "Out of memory allocating ksiginfo
for pid xxx", or it will sit there looping in the pagedaemon.
there are more details in the thread "lookup on memory shortage" on
tech-kern:
http://mail-index.netbsd.org/tech-kern/2008/09/30/msg002948.html
>How-To-Repeat:
on a system with 512M RAM and 128 or 256M swap (I'm not sure these
values are critical), run a program that will generate dirty pages in the
file cache (e.g. tar cf /root/pkgsrc.tar pkgsrc), and once there are dirty
file cache pages, start a memory-hungry program:
#include <stdio.h>
#include <malloc.h>
#include <string.h>
int main()
{
int jj = 0;
int alloc = 1024 * 1024 * 10;
while(1)
{
char *p = malloc(alloc);
if (p == NULL)
{
fprintf(stderr, "failed\n");
sleep(30);
exit(1);
}
memset(p, jj, alloc);
if (memcmp(p, p+(alloc/2), alloc/2) != 0)
{
fprintf(stderr, "corrupted memory\n");
exit(1);
}
fprintf (stderr, "%d ", jj++);
}
}
>Fix:
unkown
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: kern-bug-people->ad
Responsible-Changed-By: ad@NetBSD.org
Responsible-Changed-When: Tue, 02 Dec 2008 10:33:19 +0000
Responsible-Changed-Why:
take
From: Andrew Doran <ad@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/40027 (pagedaemon loops on memory shortage)
Date: Tue, 2 Dec 2008 12:06:09 +0000
A rough guess at what is happening:
The first 16 pages on the inactive list are dirty anons that are not swap
backed. The pagedaemon wants to evict them but fails to allocate swap slots
for them, as all swap is in use. It moves on to the next victim page. Once
we reach a limit of 16 tries we give up and fall out of uvmpd_scan_queue().
uvmpdpol_balancequeue() should remedy this condition by dropping swap slots
from resident anons that are swap backed. However, it only scans the active
queue so can miss swap-backed pages that are on the inactive queue.
We loop back through it ad-infinitum, making no forward progress.
Andrew
From: Andrew Doran <ad@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/40027 (pagedaemon loops on memory shortage)
Date: Wed, 3 Dec 2008 14:04:57 +0000
With this patch against -current and the test program, a dual CPU machine
with 128MB RAM stalls during heavy paging activity, but eventually the
memory hog process is killed and it recovers.
Memory: 3728K Act, 2156K Inact, 500K Wired, 4484K Exec, 124K File, 95M Free
Andrew
Index: uvm_km.c
===================================================================
RCS file: /cvsroot/src/sys/uvm/uvm_km.c,v
retrieving revision 1.102
diff -u -p -r1.102 uvm_km.c
--- uvm_km.c 1 Dec 2008 10:54:57 -0000 1.102
+++ uvm_km.c 3 Dec 2008 13:53:34 -0000
@@ -589,7 +589,9 @@ uvm_km_alloc(struct vm_map *map, vsize_t
loopva = kva;
loopsize = size;
- pgaflags = UVM_PGA_USERESERVE;
+ pgaflags = 0;
+ if (flags & UVM_KMF_NOWAIT)
+ pgaflags |= UVM_PGA_USERESERVE;
if (flags & UVM_KMF_ZERO)
pgaflags |= UVM_PGA_ZERO;
prot = VM_PROT_READ | VM_PROT_WRITE;
@@ -698,7 +700,7 @@ uvm_km_alloc_poolpage_cache(struct vm_ma
return 0;
KASSERT(!pmap_extract(pmap_kernel(), va, NULL));
again:
- pg = uvm_pagealloc(NULL, 0, NULL, UVM_PGA_USERESERVE);
+ pg = uvm_pagealloc(NULL, 0, NULL, waitok ? 0 : UVM_PGA_USERESERVE);
if (__predict_false(pg == NULL)) {
if (waitok) {
uvm_wait("plpg");
@@ -724,7 +726,7 @@ uvm_km_alloc_poolpage(struct vm_map *map
vaddr_t va;
again:
- pg = uvm_pagealloc(NULL, 0, NULL, UVM_PGA_USERESERVE);
+ pg = uvm_pagealloc(NULL, 0, NULL, waitok ? 0 : UVM_PGA_USERESERVE);
if (__predict_false(pg == NULL)) {
if (waitok) {
uvm_wait("plpg");
Index: uvm_map.c
===================================================================
RCS file: /cvsroot/src/sys/uvm/uvm_map.c,v
retrieving revision 1.264
diff -u -p -r1.264 uvm_map.c
--- uvm_map.c 1 Dec 2008 10:54:57 -0000 1.264
+++ uvm_map.c 3 Dec 2008 13:53:35 -0000
@@ -4616,7 +4616,8 @@ again:
* for simplicity, always allocate one page chunk of them at once.
*/
- pg = uvm_pagealloc(NULL, 0, NULL, 0);
+ pg = uvm_pagealloc(NULL, 0, NULL,
+ (flags & UVM_KMF_NOWAIT) != 0 ? UVM_PGA_USERESERVE : 0);
if (__predict_false(pg == NULL)) {
if (flags & UVM_FLAG_NOWAIT)
return NULL;
Index: uvm_page.c
===================================================================
RCS file: /cvsroot/src/sys/uvm/uvm_page.c,v
retrieving revision 1.140
diff -u -p -r1.140 uvm_page.c
--- uvm_page.c 4 Jul 2008 10:56:59 -0000 1.140
+++ uvm_page.c 3 Dec 2008 13:53:35 -0000
@@ -1072,6 +1072,7 @@ uvm_pagealloc_strat(struct uvm_object *o
struct uvm_cpu *ucpu;
struct vm_page *pg;
bool use_reserve;
+ lwp_t *l;
KASSERT(obj == NULL || anon == NULL);
KASSERT(anon == NULL || off == 0);
@@ -1079,6 +1080,15 @@ uvm_pagealloc_strat(struct uvm_object *o
KASSERT(obj == NULL || mutex_owned(&obj->vmobjlock));
KASSERT(anon == NULL || mutex_owned(&anon->an_lock));
+ /*
+ * make kernel reserve pages available if called by a kernel
+ * thread or a realtime thread.
+ */
+ l = curlwp;
+ if (__predict_true(l != NULL) && lwp_eprio(l) >= PRI_KTHREAD) {
+ flags |= UVM_PGA_USERESERVE;
+ }
+
mutex_spin_enter(&uvm_fpageqlock);
/*
Index: uvm_pdaemon.c
===================================================================
RCS file: /cvsroot/src/sys/uvm/uvm_pdaemon.c,v
retrieving revision 1.96
diff -u -p -r1.96 uvm_pdaemon.c
--- uvm_pdaemon.c 3 Dec 2008 11:43:51 -0000 1.96
+++ uvm_pdaemon.c 3 Dec 2008 13:53:35 -0000
@@ -294,20 +294,20 @@ uvm_pageout(void *arg)
needsfree = uvmexp.free + uvmexp.paging < uvmexp.freetarg;
needsscan = needsfree || uvmpdpol_needsscan_p();
- mutex_spin_exit(&uvm_fpageqlock);
/*
* scan if needed
*/
- if (needsscan)
+ if (needsscan) {
+ mutex_spin_exit(&uvm_fpageqlock);
uvmpd_scan();
+ mutex_spin_enter(&uvm_fpageqlock);
+ }
/*
* if there's any free memory to be had,
* wake up any waiters.
*/
-
- mutex_spin_enter(&uvm_fpageqlock);
if (uvmexp.free > uvmexp.reserve_kernel ||
uvmexp.paging == 0) {
wakeup(&uvmexp.free);
@@ -870,7 +870,9 @@ uvmpd_scan_queue(void)
if (swapcluster_allocslots(&swc)) {
mutex_exit(slock);
+#if 0
dirtyreacts++; /* XXX */
+#endif
continue;
}
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: ad@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/40027 (pagedaemon loops on memory shortage)
Date: Wed, 3 Dec 2008 16:51:01 +0100
On Wed, Dec 03, 2008 at 02:05:03PM +0000, Andrew Doran wrote:
> The following reply was made to PR kern/40027; it has been noted by GNATS.
>
> From: Andrew Doran <ad@NetBSD.org>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: kern/40027 (pagedaemon loops on memory shortage)
> Date: Wed, 3 Dec 2008 14:04:57 +0000
>
> With this patch against -current and the test program, a dual CPU machine
> with 128MB RAM stalls during heavy paging activity, but eventually the
> memory hog process is killed and it recovers.
>
> Memory: 3728K Act, 2156K Inact, 500K Wired, 4484K Exec, 124K File, 95M Free
I still see the problem here:
load averages: 1.17, 0.86, 0.41; up 0+00:07:05 16:16:49
42 processes: 1 runnable, 40 sleeping, 1 on CPU
CPU states: 0.0% user, 0.0% nice, 97.1% system, 0.0% interrupt, 2.9% idle
Memory: 304M Act, 149M Inact, 5824K Wired, 8924K Exec, 21M File, 20K Free
Swap: 256M Total, 256M Used, 8K Free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
0 root 126 0 0K 9568K pgdaemon 3:38 0.88% 0.88% [system]
10573 root 81 0 5904K 22M RUN 0:11 0.00% 0.00% cc1
18891 root 85 0 76K 4K wait 0:02 0.00% 0.00% <pbulk-build
3229 bouyer 43 0 96K 844K CPU 0:00 0.00% 0.00% top
Did you try writing large files while running the memory hog program ?
I found that producing dirty pages to the file cache while running short
or memory makes the problem much more likely to happen.
--
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr
NetBSD: 26 ans d'experience feront toujours la difference
--
From: Andrew Doran <ad@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/40027 CVS commit: src/sys/uvm
Date: Sat, 13 Dec 2008 11:22:09 +0000 (UTC)
Module Name: src
Committed By: ad
Date: Sat Dec 13 11:22:09 UTC 2008
Modified Files:
src/sys/uvm: uvm_swap.c
Log Message:
PR kern/40027 pagedaemon loops on memory shortage
uvm_swapisfull: don't count some small portion as it may be inaccessible to
us at any given moment, for example if there is lock contention or if pages
are busy.
To generate a diff of this commit:
cvs rdiff -r1.140 -r1.141 src/sys/uvm/uvm_swap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Andrew Doran <ad@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: PR/40027 CVS commit: src/sys/uvm
Date: Sat, 13 Dec 2008 11:35:36 +0000
On Sat, Dec 13, 2008 at 11:26:57AM +0000, Andrew Doran wrote:
>
> Module Name: src
> Committed By: ad
> Date: Sat Dec 13 11:26:57 UTC 2008
>
> Modified Files:
> src/sys/uvm: uvm_pdaemon.c
>
> Log Message:
> PR 40027/pagedaemon loops on memory shortage
>
> uvmpd_scan_queue:
>
> - Fix a bug that prevented the pagedaemon from making forward progress
> if (a) swap was full (b) the first 16 pages on the inactive list were
> unbusy anons not already backed by swap.
>
> - Remove redundant uvm_swapisfull() check and just try to allocate a slot.
> If it fails we know swap is full.
>
>
> To generate a diff of this commit:
> cvs rdiff -r1.96 -r1.97 src/sys/uvm/uvm_pdaemon.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: ad@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: PR/40027 CVS commit: src/sys/uvm
Date: Thu, 18 Dec 2008 21:32:05 +0100
On Sat, Dec 13, 2008 at 12:55:01PM +0000, Andrew Doran wrote:
> [...]
> On Sat, Dec 13, 2008 at 11:26:57AM +0000, Andrew Doran wrote:
> >
> > Module Name: src
> > Committed By: ad
> > Date: Sat Dec 13 11:26:57 UTC 2008
> >
> > Modified Files:
> > src/sys/uvm: uvm_pdaemon.c
> >
> > Log Message:
> > PR 40027/pagedaemon loops on memory shortage
> >
> > uvmpd_scan_queue:
> >
> > - Fix a bug that prevented the pagedaemon from making forward progress
> > if (a) swap was full (b) the first 16 pages on the inactive list were
> > unbusy anons not already backed by swap.
> >
> > - Remove redundant uvm_swapisfull() check and just try to allocate a slot.
> > If it fails we know swap is full.
With an up to date kernel I can't reproduce this problem any more.
With a loop running the test program, while a tar is running in parallel
filling up the file cache, the test system survived 20mn (it hangs in
less than a minute on netbsd-5).
thanks !
Now seeing how it behaves with a pbulk build ...
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
From: Andrew Doran <ad@NetBSD.org>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: PR/40027 CVS commit: src/sys/uvm
Date: Fri, 19 Dec 2008 08:29:56 +0000
On Thu, Dec 18, 2008 at 09:32:05PM +0100, Manuel Bouyer wrote:
> With an up to date kernel I can't reproduce this problem any more.
> With a loop running the test program, while a tar is running in parallel
> filling up the file cache, the test system survived 20mn (it hangs in
> less than a minute on netbsd-5).
Cool! I'll request a pullup today.
Thanks,
Andrew
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: ad@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: PR/40027 CVS commit: src/sys/uvm
Date: Mon, 22 Dec 2008 18:49:56 +0100
On Fri, Dec 19, 2008 at 09:50:03AM +0000, Andrew Doran wrote:
> Cool! I'll request a pullup today.
ping .... :)
I tested these 3 pullups on netbsd-5:
cvs rdiff -r1.140 -r1.141 src/sys/uvm/uvm_swap.c
cvs rdiff -r1.96 -r1.97 src/sys/uvm/uvm_pdaemon.c
cvs rdiff -r1.102 -r1.103 src/sys/uvm/uvm_km.c
cvs rdiff -r1.264 -r1.265 src/sys/uvm/uvm_map.c
cvs rdiff -r1.140 -r1.141 src/sys/uvm/uvm_page.c
and it seems to work.
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
From: Soren Jacobsen <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/40027 CVS commit: [netbsd-5] src/sys/uvm
Date: Sat, 27 Dec 2008 18:22:50 +0000 (UTC)
Module Name: src
Committed By: snj
Date: Sat Dec 27 18:22:50 UTC 2008
Modified Files:
src/sys/uvm [netbsd-5]: uvm_swap.c
Log Message:
Pull up following revision(s) (requested by bouyer in ticket #211):
sys/uvm/uvm_swap.c: revision 1.141
PR kern/40027 pagedaemon loops on memory shortage
uvm_swapisfull: don't count some small portion as it may be inaccessible to
us at any given moment, for example if there is lock contention or if pages
are busy.
To generate a diff of this commit:
cvs rdiff -r1.140 -r1.140.4.1 src/sys/uvm/uvm_swap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Andrew Doran <ad@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: PR/40027 CVS commit: src/sys/uvm
Date: Sun, 28 Dec 2008 12:14:49 +0100
On Sun, Dec 28, 2008 at 10:37:21AM +0000, Andrew Doran wrote:
> On Mon, Dec 22, 2008 at 06:49:56PM +0100, Manuel Bouyer wrote:
>
> > On Fri, Dec 19, 2008 at 09:50:03AM +0000, Andrew Doran wrote:
> > > Cool! I'll request a pullup today.
> >
> >
> > ping .... :)
> > I tested these 3 pullups on netbsd-5:
> > cvs rdiff -r1.140 -r1.141 src/sys/uvm/uvm_swap.c
> >
> > cvs rdiff -r1.96 -r1.97 src/sys/uvm/uvm_pdaemon.c
> >
> > cvs rdiff -r1.102 -r1.103 src/sys/uvm/uvm_km.c
> > cvs rdiff -r1.264 -r1.265 src/sys/uvm/uvm_map.c
> > cvs rdiff -r1.140 -r1.141 src/sys/uvm/uvm_page.c
> >
> > and it seems to work.
>
> Great, thanks. I will be issuing pullup requests including these within the
> next few days.
Well, as I didn't get news I did request the pullup, and it has been
processes yesterday.
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
From: Andrew Doran <ad@NetBSD.org>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: PR/40027 CVS commit: src/sys/uvm
Date: Sun, 28 Dec 2008 10:37:21 +0000
On Mon, Dec 22, 2008 at 06:49:56PM +0100, Manuel Bouyer wrote:
> On Fri, Dec 19, 2008 at 09:50:03AM +0000, Andrew Doran wrote:
> > Cool! I'll request a pullup today.
>
>
> ping .... :)
> I tested these 3 pullups on netbsd-5:
> cvs rdiff -r1.140 -r1.141 src/sys/uvm/uvm_swap.c
>
> cvs rdiff -r1.96 -r1.97 src/sys/uvm/uvm_pdaemon.c
>
> cvs rdiff -r1.102 -r1.103 src/sys/uvm/uvm_km.c
> cvs rdiff -r1.264 -r1.265 src/sys/uvm/uvm_map.c
> cvs rdiff -r1.140 -r1.141 src/sys/uvm/uvm_page.c
>
> and it seems to work.
Great, thanks. I will be issuing pullup requests including these within the
next few days.
Andrew
From: Andrew Doran <ad@NetBSD.org>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: PR/40027 CVS commit: src/sys/uvm
Date: Mon, 29 Dec 2008 10:29:51 +0000
On Sun, Dec 28, 2008 at 12:14:49PM +0100, Manuel Bouyer wrote:
> On Sun, Dec 28, 2008 at 10:37:21AM +0000, Andrew Doran wrote:
> > On Mon, Dec 22, 2008 at 06:49:56PM +0100, Manuel Bouyer wrote:
> >
> > > On Fri, Dec 19, 2008 at 09:50:03AM +0000, Andrew Doran wrote:
> > > > Cool! I'll request a pullup today.
> > >
> > >
> > > ping .... :)
> > > I tested these 3 pullups on netbsd-5:
> > > cvs rdiff -r1.140 -r1.141 src/sys/uvm/uvm_swap.c
> > >
> > > cvs rdiff -r1.96 -r1.97 src/sys/uvm/uvm_pdaemon.c
> > >
> > > cvs rdiff -r1.102 -r1.103 src/sys/uvm/uvm_km.c
> > > cvs rdiff -r1.264 -r1.265 src/sys/uvm/uvm_map.c
> > > cvs rdiff -r1.140 -r1.141 src/sys/uvm/uvm_page.c
> > >
> > > and it seems to work.
> >
> > Great, thanks. I will be issuing pullup requests including these within the
> > next few days.
>
> Well, as I didn't get news I did request the pullup, and it has been
> processes yesterday.
That is even better because I don't have to do the work and verification!
Thanks,
Andrew
State-Changed-From-To: open->closed
State-Changed-By: ad@NetBSD.org
State-Changed-When: Mon, 29 Dec 2008 12:45:57 +0000
State-Changed-Why:
fixed
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home