>Number:         2667
>Category:       kern
>Synopsis:       NQNFS panics in reading client after sync on writing client
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Aug  1 13:20:05 1996
>Last-Modified:
>Originator:     Sean Doran
>Organization:
	Sprintlink Engineering
>Release:        1.2_BETA
>Environment:
	
System: NetBSD chops.icp.net 1.2_BETA NetBSD 1.2_BETA (CHOPS) #1: Thu Jul 18 05:30:17 EDT 1996 smd@titan.sprintlink.net:/usr/src/sys/arch/sparc/compile/CHOPS sparc
NetBSD isis.sprintlink.net 1.2_BETA NetBSD 1.2_BETA (ISIS) #1: Fri Jul 19 14:44:35 PDT 1996     smd@isis.sprintlink.net:/usr/src/sys/arch/i386/compile/ISIS i386
NetBSD titan.sprintlink.net 1.2_BETA NetBSD 1.2_BETA (TITAN) #1: Fri Jul 19 06:35:48 EDT 1996     smd@titan.sprintlink.net:/usr/src/sys/arch/sparc/compile/TITAN sparc

>Description:
	chops and isis mount a directory from titan using
	these flags: -3,-T,-l,-q,-b,-i,-s

	If one or the other client creates a small file, the
	other will see the file has been created, but if
	the other client tries to read it, the file will
	be empty.

	If one runs 'sync' on the client that created
	the small file, the kernel on the reading client
	panics and creates a core that says
panic: trap
cannot read u area ptr for proc at 0xf8821000
        and contains practically no useful information

	I just found this bug and reproduced the
        behaviour, but I have not tried to do this with a DDB
	kernel yet, or to see what other combinations of
	reads/writes/syncs will cause the panic.

>How-To-Repeat:
	chops$ cd <mounted-filesystem>/tmp/
	chops$ date > A
	
	isis$ cat A
	isis$

	chops$ cat A
	Wed Jul 31 17:03:50 EDT 1996
	chops$ sync

	<isis panics>

>Fix:
	not yet known

>Audit-Trail:
>Unformatted: