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>