Date: Sat, 4 Apr 1998 17:51:15 -0800 (PST) From: Matthew Dillon <dillon@backplane.com> To: FreeBSD-gnats-submit@FreeBSD.ORG Subject: kern/6213: swap-mounted via NFS through vnconfig crash Message-ID: <199804050151.RAA08051@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
>Number: 6213
>Category: kern
>Synopsis: NFS-mounted swap (via vnconfig) easily crashes machine
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sat Apr 4 18:00:00 PST 1998
>Last-Modified:
>Originator: Matthew Dillon
>Organization:
Best Internet Communications
>Release: FreeBSD 3.0-CURRENT i386
>Environment:
Standalone diskless pentium running FreeBSD
>Description:
I tried to setup 256MB of swap space by creating a swap file on
r+w NFS-mounted partition, using vnconfig to configure that swap
file into a block device, and then adding it as swap space to the
standalone workstation.
It works a little, but crashes easily. I have done some minor tracking
down of the crash but not much since I don't have serial-port gdb setup
and kzip'd kernels (the workstation boots from floppy) do not include
debugging info.
>How-To-Repeat:
(On a 64MB machine) Write a simple program to allocate and
touch 20MB of ram with malloc and a for() loop:
#include <stdio.h>
int
main(int ac, char **av)
{
int b = strtol(av[1], NULL, 0) * 1024 * 1024;
char *p = malloc(b);
int i;
for (i = 0; i < b; i += 4096)
p[i] = 1;
sleep(10);
return(0);
}
Run the program three times with the workstation configured with
the NFS-mounted swap.
The kernel will panic relatively quickly and drop into the debugger
with a kernel page fault. Tentitively what is occuring is that
the NFS module is being given a WRITE command and is blowing up while
trying to convert the write buffer into mbuf's. The page fault occurs
in the bcopy().
I don't know what's wrong. The main reason I am bringing this to
your attention is that the *BEST* test of the VM system is to go
through something like vnconfig (the vn* device), and then bang on the
machine. Any missing locks or race conditions would come to the fore
quickly. It would be nice if vnodes could be treated generically and
these VM bugs fixed once and for all.
>Fix:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804050151.RAA08051>