Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!hao!boulder!sunybcs!ur-tut!ur-valhalla!micropen!dave From: dave@micropen.UUCP Newsgroups: comp.sys.ibm.pc,comp.unix.questions Subject: Re: Serial Port problems with microPort System V/286 2.2U Message-ID: <354@micropen> Date: Fri, 12-Jun-87 08:37:54 EDT Article-I.D.: micropen.354 Posted: Fri Jun 12 08:37:54 1987 Date-Received: Sat, 13-Jun-87 19:50:39 EDT References: <307@xios.XIOS.UUCP> <6102@steinmetz.steinmetz.UUCP> <479@qiclab.UUCP> Organization: Micropen Direct Writing Systems, Pittsford, NY Lines: 70 Xref: utgpu comp.sys.ibm.pc:4200 comp.unix.questions:2466 Summary: More serious problems with IBM serial ports In article <479@qiclab.UUCP>, neighorn@qiclab.UUCP (Steven C. Neighorn) writes: > In article <6102@steinmetz.steinmetz.UUCP> davidsen@kbsvax.steinmetz.UUCP (William E. Davidsen Jr) writes: > > > >One of the people here has the same problem (more or less). When > >running UUCP at 9600 baud to a VAX, he frequently gets a "double panic" > >and tss dies. It powerdown time then. > > I have been hammering at Microport for *months* about the problems with the serial port handling. In particular, cu and other programs that use serial ports when uucp is going on (even at 1200 baud) will fail--lose characters and even double (spuriously) characters. For the longest time Microport said "not our fault." After presenting much unequivocable evidence to them it boils down to this: IBM PC interrupts are faulty--it is possible to "lose" interrupts. But that does not explain everything. The "real" answer is that Microport has a large interrupt latency and does not use any hardware flow control. That is, once the 8250 receive register is full, the cts should inhibit the transmission of the next character. It doesn't. The next character comes and overwrites the preceding character (overrun error). Some devices, like terminals, which process data quickly, can deal with no flow control. Programs like cu that are connected between two Microport beasts that involve lots of characters will almost for certain fail if any other serial interrupt activity is going on. My real killer case is a digitizer that sends a position as 10 characters at 9600 baud. Microport can only recieve about 5 of them correctly and even then most are garbled. In order to make this digitizer work I need to reduce the baud all the way down to 1200 and not have any other serial port activity going on. This is to slow to be useful as a digitizer in the manner it is intended to be used. Now the TSS and the double error panics are detection that the kernal stack has overflowed its segment. (As an aside, 64k segments are toughest on global resources, like kernal stack. I have been using this system under these constraints for several months and am extremely careful with my device drivers not to have automatic variables. Our friends at Microsoft *will* release a '286 OS called OS/2. The real Achilles Heal of the '286 architecture is this kernal stack limitation. Per user space has seldom been a problem--kernal space crashes this system at least once a month. Does anyone know of Microsoft's handling of this or do they ignore the problem?) The TSS fault is caused by kernal stack recursion at the interrupt level and *should* be due to improper spl() in the interrupt section of the tty driver. Of course, Microport claims there is no bug but how does one get tty interrupt kernal stack recursion if the spl() is set such that tty interrupts are blocked while in the driver? There is a bug in spl() call in the tty driver -- very little doubt about it. Microport had better listen to this one: I cannot sell a program to run on a machine that is so fragile that a single tty or digitizer running at 9600 baud will crash the system no matter how attractive it is to have real SYS V UNIX(tm--ATT) as the OS. The fact that it took me 6 months of almost daily calls and bitching to get them to even admit there was a problem tells me a great deal about Microport. (Although in all fairness Microport has generally been an exceptionally good vendor to deal with-- technical service is top of the line in most cases.) It has been almost two months now of almost daily calls to get the serial port driver code (I am a licensed developer of Microport) in order to identify and fix these bugs and omissions. Every time I get the feeling that I'm getting the run around, I think about finding a more suitable *commercial* OS (like perhaps XENIX systemV) that has amenities like the ability to do backups on anything other than floppy disks. ("Oh yes, the streaming tape driver will be ready *any* day now" -- Microport 8/'86, 9/'86, 10/'86, 11/'86, 12/'86, 1/'87, 2/'87, 3/'87, 4/'87, 5/'87, 6/'87, ... ) My confidence is waning gentlemen. -- David F. Carlson, Micropen, Inc. ...!{seismo}!rochester!ur-valhalla!micropen!dave "The faster I go, the behinder I get." --Lewis Carroll