Hi guys..

tls@NetBSD.ORG writes:
> 
> If you're running a kernel built with my vnode_pager_sync changes (revision
> 1.23 of vnode_pager.c, of 1997/02/13 02:54:11) you should update to the
> current revision.  Revision 1.23 contained two serious bugs:
> 
>         * It did not lock the VM object associated with the vnode.  You are
>           much less likely to have seen this than
>         * It (incorrectly) removed pages from the paging queues, which caused
>           the VM system to lose track of memory.  Depending how much memory
>           your machine has, this could lead to excessive paging, the commonly
>           reported symptom, or eventual deadlock.
> 
> Credit goes to Charles Hannum for figuring this out.

This weekend whilst doing a "make build" and running a -current kernel 
generated from Feb. 15 tarballs I got the following errors:

  Feb 15 19:14:58 rizzo /netbsd: vnode: table is full
  Feb 15 19:14:59 rizzo syslogd: /var/run/utmp: Too many open files in system
  Feb 15 19:14:59 rizzo /netbsd: vnode: table is full
  Feb 15 19:14:59 rizzo /netbsd: vnode: table is full
  Feb 15 19:34:40 rizzo /netbsd: vnode: table is full
  Feb 15 19:34:41 rizzo syslogd: /var/run/utmp: Too many open files in system
  Feb 15 19:34:41 rizzo syslogd: /var/run/utmp: Too many open files in system
  Feb 15 19:34:41 rizzo /netbsd: vnode: table is full
  Feb 15 19:34:41 rizzo last message repeated 5 times

Weird things were starting to happen -- like root being unable to open files.

Is this another symptom of the vnode_pager_sync bugs, or is this something new?

I'm planning on compiling another -current kernel as soon as version 1.25 of 
vnode_pager.c is available.  If the problem still persists after running with 
1.25, I'd be happy to provide whatever assistance I can to finding the bug.

The system producing the above errors is a DEC Multia, 128MB RAM, 3GB of disk.

Thanks.

Later...

Greg Oster

oster@cs.usask.ca
Department of Computer Science
University of Saskatchewan, Saskatoon, Saskatchewan, CANADA