Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nexus.coast.net!news.kei.com!news.mathworks.com!gatech!howland.reston.ans.net!sol.ctr.columbia.edu!startide.ctr.columbia.edu!wpaul From: wpaul@ctr.columbia.edu (Bill Paul) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: NFS FreeBSD => HP-UX Date: 21 Jun 1995 14:56:47 GMT Organization: Columbia University Center for Telecommunications Research Lines: 83 Message-ID: <3s9bvg$k1u@sol.ctr.columbia.edu> References: <3s6rj6$dd1@gwdu19.gwdg.de> NNTP-Posting-Host: startide.ctr.columbia.edu X-Newsreader: TIN [version 1.2 PL2] Daring to challenge the will of the almighty Leviam00se, Stephan Trebels (strebel2@rihm.mpibpc.gwdg.de) had the courage to say: : Hi, : I do have Problems using our NFS Server (HP-UX 9.05) : with the one experimental FreeBSD Client. It locks up : after a definite amount of transfer (using tar on a : mounted filesys, it stops at the same file). And which file would that be? One near the beginning? one near the end? How big is it? How much gets transfered before it hangs? Inquiring minds want to know. : Yes, I DID disable TCP_EXTENSIONS in /etc/sysconfig. : Linux on the same machine works without problems. : So what? : Any ideas? Well, yes, actually... : Ciao, Stephan : P.S. The ethernet card had some problems: 3com IRQ 3 iomem 0xc8000 : port 0x300, but now, the kernel knows about it. ftp, telnet, : everything else works FAST. but the moment, I use the NFS server, it : just doesn't work. : Back to Linux? Forward to The Hurd? Sigh. No, first you give us more information. You said the card was a 3Com, but you didn't say what *KIND* of 3Com. They make more than one kind of adapter you know. Guys, we aren't Micro$oft here: we don't have magic software hidden in FreeBSD that automatically examines every aspect of your machine and then mails it to us. We leave it to you to tell us the details, so do a good job. A couple of things: - Make absolutely sure that there's nothing conflicting with IRQ 3. Since you say that other TCP/IP applications work properly, this is not likely to be a problem but, as they say, "it couldn't hoit." - If this is an 8-bit 3Com 3c503/Etherlink II, then you might need to lower the read and write buffer sizes a little. I have encountered some newer 8-bit Etherlink II cards that don't seem to need this, but the older ones can't seem get by without it. Try mounting the NFS filesystem like this: # mount -o -r4096,-w4096 server:/some/file/system /some/mount/point You may need to add the 'resvport' option to the list: # mount -o resvport,-r4096,-w4096 server:/some/file/system /some/mount/point Once this is done, try to induce the error again. If all goes well, add the -r4096,-w4096 options to /etc/fstab. The problem with the 8-bit 3c503's is that they aren't fast enough to process the 8K blocks that NFS uses by default. Reducing the block size helps work around this deficiency. If you still have problems with 4K blocks, try using 1K blocks instead. I have a feeling that the reason Linux works is that it may not be using 8K blocks by default. This is a hunch however: I haven't used Linux in a while, but when I did use it, I know that the default block size was relatively small. This was due, I believe, to the fact that at the time you couldn't raise the NFS block size higher than the 386 page size, which is 4K. This, in turn, was due to the fact that Linux didn't use mbufs. But again, this was a while ago (0.99.13 was the last kernel version I used) so this restriction may no longer apply. -Bill -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~T~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Bill Paul (212) 854-6020 | System Manager Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Møøse Illuminati: ignore it and be confused, or join it and be confusing! ~~~~~~ "Welcome to All Things BSDish! If it's not BSDish, it's crap!" ~~~~~~~