>Number:         335
>Category:       port-hp300
>Synopsis:       NFS server is severely broken on hp300
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jul 10 00:35:01 1994
>Originator:     Root
>Organization:
"	Computer Science Outreach Services, Oregon State University"
>Release:        NetBSD 0.9C-current
>Environment:
	
System: NetBSD foundation 0.9C NetBSD 0.9C (FOUNDATION) #0: Sat Jul 9 23:30:47 PDT 1994 root@foundation:/tmp_mnt/jadzia/info/BSD/src/sys/arch/hp300/compile/FOUNDATION hp300


>Description:
	[I have sent mail to members of core about this already, but I figured an update was in order, as long with
	 an official pr.]

	Under a very current system (July 7th sources) NFS service is very much broken. This is not the case on the i386,
	running sources from the same day.

	When mounting a file system over NFS from an hp300, all data within the files is returned as nothing but
	zereos.  File modes, sizes, etc., show up fine, just no data.

	When attempting to write to a file system over NFS, when the file system is mounted on anything, including
	SunOS, new files are unable to have any data written to them.  Mode, owner, etc., will be set fine, but
	no data.  Ther write() syscall will *succeed* on the remote machine ('remote' as in machine mounting
	the file system), but the close() syscall will return EFBIG - File too large.

	The local ('server') machine has no problems accessing, modifing, or otherwise using the same local
	file system.

	There are no problems with mounting remote file systems on the hp300.

	Kernel and user land are vintage and utterly pure July 7th sources.
>How-To-Repeat:
	Mount a file system that is being served by an hp300 and attempt the above types of usage.
>Fix:
	Unknown, at the moment.
>Audit-Trail:
>Unformatted:


------------------------------------------------------------------------------