NetBSD Problem Report #22725
Received: (qmail 9094 invoked by uid 605); 9 Sep 2003 01:09:31 -0000
Date: Tue, 9 Sep 2003 01:09:28 +0000 (UTC)
Subject: kernel panic while attempting mkfifo on NFS volume
>Synopsis: kernel panic while attempting mkfifo on NFS volume
>Arrival-Date: Tue Sep 09 01:10:00 +0000 2003
>Last-Modified: Tue Apr 09 15:49:49 +0000 2013
>Originator: Pascal Schmidt
NetBSD neptune.local 1.6.1 NetBSD 1.6.1 (GENERIC) #0: Tue Apr 8 12:05:52 UTC 2003 firstname.lastname@example.org:/autobuild/netbsd-1-6/i386/OBJ/autobuild/netbsd-1-6/src/sys/arch/i386/compile/GENERIC i386
When attempting to run mkfifo on an NFS volume exported from a user-space NFS server on localhost, I get a protection fault inside the kernel.
output on the console (copied by hand) is:
kernel: protection fault trap, code=0
Stopped in pid 2075 (mkfifo) at memcpy+0x1a: repe movsl (%esi),%esi(%edi)
attempting to sync from the debugger does not work then:
syncing disks... 7 done
panic: lockmgr: locking against myself
Stopped in pid 2075 (mkfifo) at cpu_Debugger+0x4: leave
Even if this is due to a bug in the NFS server, it should probably
not hang the kernel.
1. make sure rpcbind is running, but in-kernel NFS server not
2. download http://www.tzi.de/~pharao90/crashme.tar.gz
3. zcat crashme.tar.gz | tar xf -
4. cd crashme
6. make .depend
8. mkdir /tmp/test
9. mkdir /tmp/mnt
now as root:
11. mount_nfs -3 127.0.0.1:/tmp/test /tmp/mnt
12. mkfifo /tmp/mnt/fifo
kernel trap immediately follows
State-Changed-When: Sat, 19 Jan 2008 23:35:29 +0200
can you provide a stack backtrace?
State-Changed-When: Sun, 26 Oct 2008 23:12:15 +0000
Submitter's email is bouncing. Anyone else want to try to replicate this?
State-Changed-When: Sat, 20 Feb 2010 16:41:09 +0000
If this still is a problem with a recent NetBSD version, please re-submit.
State-Changed-When: Sun, 14 Mar 2010 18:34:39 +0000
Someone should really try to reproduce this. It is probably a bug in the
submitter's nfs server program, unfortunately (which is no longer available)
but it might not be -- either way, the nfs client should not crash just
because some nfs server does something screwy.
I have a similar issue except I am not doing a mkfifo call, at least
not explicitly. This morning I mounted a NetBSD 5.1 amd64 machine on
two different NetBSD 6.0.1 (GENERIC) amd64 machines. The dmesg output
can be viewed at the following URLs:
The systems are almost identical and yet this morning I was able to
work on druid just fine but lothlorien rebooted twice within a very
short time of starting to work on the remote FS. In both cases I was
running "pkg_rolling-replace -suv" using the mounted /usr/pkgsrc.
These are production machines so I can't risk running NFS again. I
will have to work around it for now. However, I can inspect anything
on the systems if anyone needs more info. If there is a real
possibility of solving this I can possibly try something in the middle
of the night some time but even then the system is in use.
$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.