Return to BSD News archive
Xref: sserve comp.unix.bsd:3352 comp.protocols.nfs:4184 Path: sserve!manuel!munnari.oz.au!hp9000.csc.cuhk.hk!uakari.primate.wisc.edu!ames!olivea!mintaka.lcs.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!eichin From: eichin@athena.mit.edu (Mark W. Eichin) Newsgroups: comp.unix.bsd,comp.protocols.nfs Subject: 386BSD: 16550's vs. NFS Message-ID: <EICHIN.92Aug9004425@tsx-11.mit.edu> Date: 9 Aug 92 04:44:32 GMT Sender: news@athena.mit.edu (News system) Organization: Massachusetts Institute of Technology Lines: 36 Nntp-Posting-Host: tsx-11.mit.edu overview: 386bsd on a 486/40, cgd's com driver, a 16550 UART, and SLIP. ftp works fine; NFS loses entirely. Any suggestions? The full story: I've had "com0: silo overflow" errors since I started running 386BSD. [side note: PC's don't *have* silos... VAXen do.] Various amounts of hacking (with the help of <dmuntz> and others) tamed them sufficiently that running at 19200bps would only generate hundreds per minute, with syslog taking care of it. 0.1 came along and though the release driver is far worse than what I was using in 0.0, <cgd>'s driver is better (though there are still silo errors.) The theory was that since I have a "normal" 2s/1p I/O card (with some random VLSI chip, but no fifos) that upgrading to a 16550 chip would solve these problems. So at the KGP show/sale today, I picked up an AST four-port card with socketed 16450's and dropped in 16550s to replace them. [If you're familiar with the card: in "non compatible" mode, the interrupts never reach the bus... but in compatible mode, it works fine. Any ideas why?] Now, at 38400bps I got "133480 bytes sent in 34 seconds (3.9 Kbytes/s)" from ftp over SLIP, with no silo errors during the transfer (with xntpd running as well.) So I tried doing some ls'es over NFS, which had given me problems before. Small directories went fine; I hit a large one and lost... *no* silo errors, the packets are making it to the machine cleanly -- but I'm still getting NFS timeouts. (The breakout box shows only intermittent traffic up to the point of the timeout.) Any suggestions? I'll try gathering other data, but would be interested in any suggestions as to potentially profitable lines of inquiry. (Most NFS problems I've dealt with before went away when the network layer problems were fixed...) _Mark_ <eichin@athena.mit.edu> MIT Student Information Processing Board Cygnus Support <eichin@cygnus.com>