learn@igloo.UUCP (william vajk) (10/20/88)
That darned serial driver problem under microport. Haven't we heard enough about it yet ? Not really. I waited a year after I got microport, and with some promise of a fixed driver, I ordered my upgrade to 2.2. The serial drivers were still damaged. Igloo would not maintain a newsfeed with other activity on the system. I tried a different serial card (recommended by microport) which didn't help. I received the newest latest and greatest driver, which was supposed to fix everything, it didn't. I had, in there somewhere, been told it was my hardware, which was replaced. I moved up to Denninger's autobaud getty to improve the connectability of the telebit at 9600, but still there were lost characters and lost feeds. And there were complaints by users of lost characters. And cu was practically worthless. And 9600 baud attempted logins from ddsw1 (login id dduucp) showed in ps as dduup regularly when the system had other activity, not even a severe load. Think of it, potentially every 5th character lost. On top of all this rode the suggestion that there were intelligent serial cards on the market. I balked at the price and the concept. Microport should, by all rights, be fixable without adding many hundreds of dollars to the cost of the machinery and someone else's software. Then came a discussion reflecting the _wonder_ that any form of unix would run as well as it does under the '286 chip and all the reasons why it shouldn't be able to. One fine day, I read a suggestion by John Zeeff about using a 16550A chip in place of the 16450 as the former contains an FIFO which could be used to queue incoming characters while the cpu was busy elsewhere. Sounded like a great idea, and a third party xenix driver was created, and porting the code to microport was begun. A couple of revisions of that port, which is still in process of fine tuning, were tested on igloo. There are some minor problems in initializing it to talk to a modem. I saw quite a nice demonstration on a null modem line using my hardware. I'll, for the moment, leave announcement of this continuing effort to the authors of the driver. As a result of the new third party driver project, a friend and igloo user, John Welch decided to design and create an inexpensive dumb serial card to take advantage of the 16550A chip and the new driver. In the course of discussions, I badgered him to look at the specs on the chip to determine if there weren't some simple initialization sequence which could be invoked to turn on the FIFO feature, one which could perhaps make the chip self sustaining. Several hours later, not only was it determined that yes, indeed there is such a feature, but the code was also written and installed on igloo. The replacement of the 16450 by a 16550A took only the effort of plugging in the new chip in place of the old. Standard cautions against electrical static are advised. Briefly explained, the software John uses to initialize the chip sets a depth of FIFO fillup to 8 characters, and the cpu is interrupted, all this utilizing the semi-intelligent merits of the 16550A itself, no cpu specific horsepower required. It also appears that an x-off is issued out the port.a The 16550A handles flow control whenever its buffer is about to overflow. Testing of this feature began immediately. I polled at 9600 baud, logged in on the other phone line, and did a 10 minute screen dump (cat * in a directory with only readable text files.) Normally, the effects of logging in would by themselves have been enough to lose the newsfeed, let alone a continuous screen dump. Yes, most assuredly, one could visually note the slowdown in the newsfeed, with some brief off-on intervals on a semi-regular basis, but the newsfeed itself continued. The newsfeed complete, I cu'd out and logged back in to igloo on a loopback thru ma bell. With the system heavily loaded by the unbatching going on (and 16 bit uncompress, etc) I catted the same files as before. Yes, the screen was somewhat jerky, as one would expect, but not a single character was lost. I then logged into chinet using igloo's cu, and was able to determine that even talking to a fast machine resulted in no lost characters while igloo was still under a decent load. Yes, the screen was somewhat jerky at 2400 baud, but one miracle at a time is quite sufficient. Doubtless, addition of a new driver will make matters better and the third party driver I mentioned earlier holds some promise of improving performance while running 16450's. In the meantime, the problems I have with the serial drivers have been repaired at minimal cost by another third party. Now, if only someone would undertake to fix the two drive problem. There's been some mention that the fix is included in the new upgrade. I'll take that final plunge. I've flamed at microport for a long time regarding these issues. I now rest my case regarding the serial drivers. That has been fixed inexpensively. Thanks to John Zeeff for calling the new chip to our attention, and to John Welch for digging into the matter and writing a the code that works. John Welch is of the opinion, as am I, that there has been enough suffering at the hands of microport already, and that this little piece of software should be placed in the public domain. The source code follows in another article. Neither of us makes any representations about it other than it is doing a fine job at igloo. Use it at your own risk. Bill Vajk learn@igloo
jjw@igloo.UUCP (John Welch) (10/20/88)
#--------------------------------CUT HERE-------------------------------------
#! /bin/sh
#
# This is a shell archive. Save this into a file, edit it
# and delete all lines above this comment. Then give this
# file to sh by executing the command "sh file". The files
# will be extracted into the current directory owned by
# you with default permissions.
#
# The files contained herein are:
#
# -rw-r--r-- 1 root sys 6344 Oct 18 19:55 16550.c
#
echo 'x - 16550.c'
if test -f 16550.c; then echo 'shar: not overwriting 16550.c'; else
sed 's/^X//' << '________This_Is_The_END________' > 16550.c
X/******************************************************************************
X 16550
X a utility that iturns on the FIFO of a NS 16550 chip
X by John Welch, of Igloo Computers
X Public Domain Software
X Hobbyists, feel free to use, abuse, pirate and re-distribute this program.
X Commercial use prohibited without consent of the author.
X Send fan mail to jjw@igloo
X Send flames to jjw@/dev/null
X******************************************************************************/
X#include <sys/types.h>
X#include <sys/io_op.h>
X#include <fcntl.h>
X
Xint fd;
Xvoid outb();
Xextern int errno;
X
Xmain()
X{
X
X
X/*
X I've waded through the NS 16550 docs for several days now,
X and what follows seems accurate enough.
X At any rate, the basic idea is that a 16550 with FIFO enabled
X has (*FINALLY!*) cured igloo's problems with losing newsfeeds. I
X thought I'd make this available to the net in the hopes that it may
X help other people who've been singing the 'microport lost character
X blues.' As microport has been unable to cure this, we finally fixed
X it ourselves. By the way, if you aren't tech-y, this may bore you
X to death. I've got it written to patch tty0 and tty1, and since on a
X 16450 or earlier this register isn't writable it should cause no
X problems. Just un-shar it by typing
X sh 16550.shar
X and compile this with
X cc -o 16550 -O 16550.c
X It might be a good idea to chmod this to 700, to prevent users from
X flushing the buffers on you. Adding this to the inittab file or some
X such place should be all thats needed. Run it once at boot-up and
X forget it.
X A bit of history here: Microport's serial port drivers are
X brain-dead. Apparently the problem is with the high-water mark in
X the kernel, and so it's *not* fixable with new drivers. What this means
X is that you lose characters sometimes. It is particularly noticable
X while doing a 9600-baud newsfeed on one serial line while another
X user on the other line is cat-ing a text file at 300 baud. Usually
X when this happens, you get many errors during the newsfeed and as
X often as not you lose the feed altogether. Microport has been told of
X this problem many times, and they've piddled and fuddled and moped
X around trying to fix it. At first they said we should get faster
X hardware because an 8Mhz AT couldn't handle 9600 baud. Fine, we found
X a place that loaned us a 20Mhz 0-wait 4Mbyte 386 board for a weekend.
X Guess what??? The problem was just as bad as before. Then they sent
X us new driver to install, which did not help the problem. They then
X suggested that we need a smart serial card, to the tune of around
X $1500 or so. They think that 9600 baud cannot be done on these machines.
X That's bull-squat, folks! XENIX does 9600 baud just fine. Microport is
X unable and unwilling to fix this problem. We had to explore alternate
X ways of doing it ourselves, preferrably without costing us hobbyists
X an arm and a leg. We feel we've found an acceptable solution with the
X 16550 UART chip.
X The 16550 is a half-way step between a 'smart' serial card
X and the usual 16450-type 'dumb' card. Using the FIFOs in the 16550
X can not only prevent lost characters, but can result in more efficient
X CPU utilization, with less time wasted in processor overhead to read
X each character sent. It does this by a device called a FIFO buffer, a
X First-In, First-Out scheme. When receiving characters, the 16550 will
X only interrupt the CPU when one of two events happens: When enough
X characters have been received (you can define 'enough' to be 1, 4, 8
X or 14) or when at least 1 character has been received and there has
X not been another character come through for 4 times the time 'width'
X of a character. In this manner, when the CPU finally gets interrupted,
X much more data can be dumped to the CPU at once, cutting down on all
X the overhead involved in context-swiching and so forth.
X In addition, if the CPU takes too long to read the FIFO, the
X 16550 will send its own flow-control to throttle back the incoming
X data, preventing buffer over-runs that have plagued microport from day
X one.
X The 16550 chip is a drop-in replacement for the 16450, and it
X costs about $25 or so (not much more than the 16450). With this chip
X and a trivial amount of software, you can not only cure microports
X brain-dead serial device driver problems, but you can also enjoy most
X of the benefits of a 'smart' card with very little cost.
X What follows is an explaination of what this program does and
X why it does it. If you have multi-port 'dumb' boards with 8250's,
X 16450's or whatever, you *should* be able to replace those chips with
X 16550s and modify this program to set (base+2) for each port.
X tty0's base address is 3f8. The FIFO control register is at
X base+2 (3fa). The byte written at this address is defined as follows:
X
X Bits 7 & 6 define at what level the 16550 interrupts the CPU. 11 is 14
X bytes deep, 10 is 8 bytes deep, 01 is 4 bytes deep and 00 is 1 byte deep.
X
X Bits 5 & 4 are not used, so I set them to 00.
X
X Bit 3 defines the performance of some pins that are not used on the
X 16450, so it's not likely to be of consequence to anything we do. I've
X chosen to keep them performing the way a 16450 would, setting this bit
X 0.
X Bit 2 clears and resets the transmit FIFO.
X Bit 1 clears and resets the Receive FIFO.
X Bit 0 turns the FIFO buffering on.
X To turn on the FIFO at tty1 to a 4-byte level, one should
X write a 0x47 to port 0x2fa. To set tty0 at the maximum FIFO level,
X send 0xc7 to port 0x3fa. To disable FIFOs at tty1 send 0 to 0x2fa.
X*/
X
X
X if ((fd = open("/dev/mem",O_RDWR)) == -1) /* open memory device for read/write */
X {
X perror("Open /dev/mem");
X exit(1);
X }
X
X
X outb(0x3fa,0x87); /* this turns on tty0's FIFO, 8 characters deep */
X outb(0x2fa,0x87); /* this turns on tty1's FIFO, 8 characters deep */
X
X close(fd); /* all done setting up FIFOs. */
X}
X
X
Xvoid outb(portno, data)
Xint portno;
Xunsigned char data;
X{
X io_op_t iop;
X
X iop.io_port = portno;
X iop.io_byte = data;
X errno = 0; /* clear error indicator */
X ioctl(fd, IOCIOP_WB, &iop); /* write the data to that port */
X if (errno)
X printf("Error setting port %04x\n",portno);
X /* send to stdout so they can re-direct easier */
X}
X
________This_Is_The_END________
if test `wc -l < 16550.c` -ne 138; then
echo 'shar: 16550.c was damaged during transit (should have been 138 bytes)'
fi
fi ; : end of overwriting check
exit 0
--
==========================================================================
John Welch <backbone>!jjw@igloo
"Oh, reality - it's not for me, and it makes me laugh,
but fantasy world, and those Disney girls... I'm coming back!"rolfe@w3vh.UUCP (Rolfe Tessem) (10/22/88)
In article <1058@igloo.UUCP>, learn@igloo.UUCP (william vajk) writes: > > That darned serial driver problem under microport. Haven't we heard > enough about it yet ? > > Not really. > > I waited a year after I got microport, and with some promise of a fixed > driver, I ordered my upgrade to 2.2. The serial drivers were still damaged. > Igloo would not maintain a newsfeed with other activity on the system. I > tried a different serial card (recommended by microport) which didn't help. > I received the newest latest and greatest driver, which was supposed to fix > everything, it didn't. > As has pointed out in this newsgroup before, the serial port thing seems to be very hardware-specific. I run 2.3L and my system has a 9600 baud newsfeed and does a lot of other serial I/O (it's a 10Mhz AT clone). It also runs unattended for weeks at a time, and has not crashed in many months. At one time I too had a lot of double-panics; then one afternoon I got a lightning surge which took out my serial card. On replacing it, everything worked great (these are just regular dumb serial ports). Moral of the story: don't flame the software unless you're absolutely sure it's not a hardware problem. -- UUCP: uunet!w3vh!rolfe | Rolfe Tessem INTERNET: rolfe@w3vh.uu.net | P.O. Box 793 AMPRNET: rolfe@w3vh.ampr.org [44.44.0.1] | Great Barrington, MA 01230 PACKET RADIO: w3vh@wa2pvv | (413) 528-5966
cwiener@crlabs.CRLABS.COM (Chris Wiener) (10/22/88)
In article <364@w3vh.UUCP> rolfe@w3vh.UUCP (Rolfe Tessem) writes: >In article <1058@igloo.UUCP>, learn@igloo.UUCP (william vajk) writes: >> >> That darned serial driver problem under microport. Haven't we heard >> enough about it yet ? >> >> Not really. >> > [stuff deleted] >Moral of the story: don't flame the software unless you're >absolutely sure it's not a hardware problem. I hope you've been following the serial port saga here in comp.unix.microport over the last year. If so, you might not be fast to jump in and assume the software is not at fault. At least Bill was involved in a possible solution (the 16550 code posted recently). As far as Microport, nothing but denials. I challenge John Plocher to provide the user community with a detailed list of changes made in V/AT Version 2.4 which substantiate his statement on the Microport BBS that most serial problems have been fixed. It's amazing how infrequently Microport personnel contribute to this newsgroup recently. Maybe they're afraid? (wonder why? :-) ) -- Christopher Wiener N2CR CR Labs, Cliffside Park, NJ DOMAIN: cwiener@CRLABS.COM UCCP: ..!killer!crlabs!cwiener
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (10/23/88)
In article <1058@igloo.UUCP> learn@igloo.UUCP (william vajk) writes: >Briefly explained, the software John uses to initialize the chip sets a >depth of FIFO fillup to 8 characters, and the cpu is interrupted, all this >utilizing the semi-intelligent merits of the 16550A itself, no cpu specific >horsepower required. It also appears that an x-off is issued out the port.a >The 16550A handles flow control whenever its buffer is about to overflow. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It's interesting that National Semiconductor Corporation doesn't know about this feature. They certainly don't claim that the chip does this. The documentation certainly doesn't claim that the chip does this. And of course I've never noticed uucico get screwed up by the chip doing this. Oh maybe that's it, it notices when uucp "g" is running and disables the feature :-) The chip *also* doesn't do hardware flow control by itself. It would have been *very* nice of NS to include that, but full duplex RTS/CTS flow contol (a la Trailblazer) is not standardized yet so few of the USART manufacturers support it. What the NS16550 does do is to provide a 16 byte RCV buffer AND a 16 byte XMT buffer; essentially grafted on top of an NS16450. When enabled the XMT FIFO will accept up to 16 bytes of data and send it without interrupting the CPU until it is empty. When enabled the RCV FIFO will buffer upto 16 bytes of data before reporting an overrun; and will interrupt when 1, 4, 8 or 14 bytes (as programmed) of data have been received. The big limitations of this chip lie in the complete lack of built in flow control given that there is no way of controlling the data in the FIFO's. There is *no* way of knowing how much data is in either FIFO, other than that there is a least one character available to read in the RCV FIFO and the XMT FIFO is not empty. This leads to problems for sending. To reduce overheads you want to fill up the XMT FIFO with 16 bytes of data. But if you then receive an XOFF or CTS drops you don't have any control over the data in the XMT FIFO; other than flushing it. If you flush you can't tell what was flushed. So you basically have to just let it drain. So you have to tailor the amount of data you put into the XMT FIFO to what is receiving at the far end. The Trailblazer fortunately does work well and will accept 16 bytes without problems. The lack of built in flow control for inbound data means that this must be done in the driver at a higher level. Usually you just let the line discipline routines (ttin) handle it. It T_BLOCK's when more than TTXOHI characters have been received. If you want to support RTS flow control then you need an extra test in your rintr routine to drop RTS when more than (for example) TTXOHI routines characters have been put into the raw clist. This means that you can't count on flow control for more than regulating the amount of data you have received so that you don't overflow your clist's. You can't use it to prevent overruns in your USART. AT 19.2 kbps you have about 500 microseconds to respond to a received data interrupt with an NS16450, as it simply buffers one character. What the NS16550 does for you is to extend this time considerably. For example if you set the interrupt level to 8 characters, you then have 8 * 500 or 4 milliseconds to respond before the RCV FIFO will overrun. But if you don't respond in that time it will still overrun. The other big problem is not related to the USART but to the way interrupts are used in the PC architecture. If you have a card with (for example) 4 USART's on it, generating one interrupt; you must check each and everyone of the USART's and ensure that it does not have an interrupt pending for *EVERY* interupt you receive. Plus to make things reliable you must do something like: restart:; for ( i = 0; i<MAXUSARTS; i++) { if ( haveint(i) ) { switch(whichint(i)){ .... }; goto restart; } } This is because you have to ensure that you go from start to finish without encountering *ANY* interrupts before you *KNOW* that every USART has brought it's interrupt line down so that the PIC will acknowledge the next interrupt. If you don't then you can get a situation where you have left a USART with an interrupt high and you well *NEVER* receive another interrupt for that board. What would really help here would be a little smarts on the part of the board manufacturers so that you could just go through the USART's once. Even better would be a status register telling you which USART's had an active interrupt. -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532
learn@igloo.UUCP (william vajk) (10/23/88)
In article <364@w3vh.UUCP>, rolfe@w3vh.UUCP (Rolfe Tessem) writes: > At one time I too had a lot of double-panics; then one afternoon > I got a lightning surge which took out my serial card. On > replacing it, everything worked great (these are just regular > dumb serial ports). I believe if you had read the entire article you might have understood what it was really about. > Moral of the story: don't flame the software unless you're > absolutely sure it's not a hardware problem. And don't declare hardware problems unless you've been zapped by lightning. Those neurons aren't replacable. Take good care of what's remaining. Bill Vajk learn@igloo
plocher@geowhiz.UUCP (John Plocher) (10/26/88)
In article <601@crlabs.CRLABS.COM> cwiener@crlabs.UUCP (Chris Wiener) writes: >Microport BBS that most serial problems have been fixed. It's amazing how >infrequently Microport personnel contribute to this newsgroup recently. Maybe >they're afraid? (wonder why? :-) ) The reason you haven't heard much is two-fold: 1) I usually don't bother responding to "flames", and 2) I installed news3.0 & managed to trash our news interface to the world. :-( Number 2 is something which is being fixed, alas, number 1 is a bit harder. As to the detailed list, I'll see what I can come up with. >Christopher Wiener N2CR CR Labs, Cliffside Park, NJ >DOMAIN: cwiener@CRLABS.COM UCCP: ..!killer!crlabs!cwiener -John Plocher
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (10/26/88)
In article <914@geowhiz.UUCP> plocher@uport.UUCP (John Plocher) writes: > 2) I installed news3.0 & managed to trash our news interface to the world. > What do you think of new3.0? Is it faster, better, easy to install? -- Jon Zeeff Ann Arbor, MI umix!b-tech!zeeff zeeff@b-tech.ann-arbor.mi.us
rfarris@serene.CTS.COM (Rick Farris) (10/27/88)
In article <914@geowhiz.UUCP> plocher@uport.UUCP (John Plocher) writes:
`
`The reason you haven't heard much is two-fold:
` 1) ...
` 2) I installed news3.0 & managed to trash our news interface to the world.
` :-(
`
` -John Plocher
Hmm, I hope that's not an example of your expertise in software development
techniques...
:-)
Rick Farris rfarris@serene.cts.com voice (619) 259-6793
POB M The OTH Gang public access 259-7757
Del Mar CA 92014 ...!uunet!serene!rfarris serene.uucp 259-3704rolfe@w3vh.UUCP (Rolfe Tessem) (10/29/88)
In article <1071@igloo.UUCP>, learn@igloo.UUCP (william vajk) writes: > In article <364@w3vh.UUCP>, rolfe@w3vh.UUCP (Rolfe Tessem) writes: > > > > At one time I too had a lot of double-panics; then one afternoon > > I got a lightning surge which took out my serial card. On > > replacing it, everything worked great (these are just regular > > dumb serial ports). > > I believe if you had read the entire article you might have understood > what it was really about. > I certainly read the entire article and understood what it was really about. My point was simply that there are very vanilla hardware configurations out here on which Microport System V/AT works great. That it didn't work well for you is unfortunate, and I'm glad your fix worked out well. To reiterate: my personal experience suggests that there is a lot of flaky serial hardware floating around that causes problems with Microport. Some serial cards seem to work fine; plug another one in and it's double panic city. You draw you own conclusions; personally, I haven't had a double panic in months. -- UUCP: uunet!w3vh!rolfe | Rolfe Tessem INTERNET: rolfe@w3vh.uu.net | P.O. Box 793 AMPRNET: rolfe@w3vh.ampr.org [44.44.0.1] | Great Barrington, MA 01230 PACKET RADIO: w3vh@wa2pvv | (413) 528-5966
jay@splut.UUCP (Jay Maynard) (10/29/88)
In article <914@geowhiz.UUCP> plocher@uport.UUCP (John Plocher) writes: > 2) I installed news3.0 & managed to trash our news interface to the world. > :-( Did you install news 3 on your 286 or 386 system? I've been trying to get news 3 running for 3 months on my 286. Unfortunately, I've never even compiled it successfully - every time I try, either my system double panics, or, if I've been a good boy and lived cleanly for the previous month, I merely have to put up with a coredump from make. I've tried everything up to patchlevel 5; I have patchkit 6, and, one day when I have a few hours to kill running fsck twice on all my filesystems after the double panics I'm sure to get, I'll try it again. If you got it going on a 286, please pass along what you did to get it to work. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------- {killer,bellcore}!tness1! | "Dukakis" is just Greek for "Mondale".