Date: Fri, 10 Nov 1995 16:50:29 +1100 (EST) From: michael butler <imb@scgt.oz.au> To: jgreco@brasil.moneng.mei.com (Joe Greco) Cc: geoff@schwing.ginsu.com, hackers@freebsd.org Subject: Re: I/O woes. Message-ID: <199511100550.QAA15021@asstdc.scgt.oz.au> In-Reply-To: <199511100413.WAA23738@brasil.moneng.mei.com> from "Joe Greco" at Nov 9, 95 10:13:42 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Joe Greco writes: > > My configuration is pretty standard. I'm using an older 486/33 with 16 > > megs of RAM and ISA bus. The ports are all controlled by 16550s. Do I > > have to do anything special to get them operating with the 16550s > > properly? I've got one modem hooking me to the internet via 28.8 modem > > and two dial-up 14.4 modems for user access. Kinda a micro ISP. ;) You should have little trouble with this .. > 1) you should ALWAYS use hardware flow control unless you have a REALLY good > reason not to. REALLY good, as in, the device you are talking to doesn't > support it. That's the ONLY reason not to. > 2) note, I don't know if the current getty in FreeBSD will allow you to set > this up "right". I've used my own severely hacked getty since the later > days of 386BSD/earlier days of FreeBSD because there was tons of lacking > functionality. Part of this was to add "proper" hardware handshaking > support because there was no gettytab flag to turn it on. I use mgetty because it does this and more .. it allows me to set the modems so that they don't auto-answer if the machine's down - saving my customer's phone bill connecting to a modem with nothing behind it. There's another motivation, however. All three -current machines I run accept inbound fidonet calls .. mgetty is the only getty (that I know of) which supports this. These machines are a 386DX/40 (Opti 386/WB), 486DX/33 (UMC) and 486DX2/66 (SiS) .. all fitted with 16550s and at least 16 meg of RAM. The only machine that gives me trouble is the 486DX/33 .. it will overflow the 16550 FIFOs if sio.c is left in "standard" form. Dropping the RX trigger point to 8 (line 1841 in -current) solved the problem. Another nit with (apparently) memory/cache timing on the same machine is yet to be fully resolved. All of them feed several newsfeeds with V.34/V.FC modems and are fed themselves via ISDN. Generally speaking, it works and it's proven to be more stable than the commercial platforms I've used in the past, michael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511100550.QAA15021>