greg@xios.XIOS.UUCP (Greg Franks) (05/26/87)
Apologies to microport, because we have sent them a fax already, but we
are in a rush for a fix.....
With Microport's Unix System V (release 2.2U) running on a genuine IBM PC
AT, select a free port on the com1 board and spawn a getty process on
it. Connect a 9600 baud terminal to the port. "cat" a large file to
the port. Output to the terminal will hang after a random amount of
data has been transmitted. This phenomena can also be observed when
scrolling through a file using vi. Tping any character causes output to
resume.
Is anyone else having this same problem? And, more importantly, does
anyone have a fix?? We have the linkkit.
Please respond using EMail or Call collect
(613) 725-5411
Thanks in advance.
--
Greg Franks (613) 725-5411 "Vermont ain't flat"
{net-land}!utzoo!dciem!nrcaer!xios!greg
(Other paths will undoubtably work too - your mileage will vary)greg@xios.XIOS.UUCP (Greg Franks) (05/28/87)
In article <307@xios.XIOS.UUCP> greg@xios.UUCP (I) write: >With Microport's Unix System V (release 2.2U) running on a genuine IBM PC >AT, select a free port on the com1 board and spawn a getty process on >it. Connect a 9600 baud terminal to the port. "cat" a large file to >the port. Output to the terminal will hang after a random amount of >data has been transmitted. This phenomena can also be observed when >scrolling through a file using vi. Typing any character causes output to >resume. Well - we just got some new IBM PC AT's from whereever, with genuine comm boards, and the problem magically went away. Never trust a rental... :-( :-( :-( :-( *** sigh *** -- Greg Franks (613) 725-5411 "Vermont ain't flat" {net-land}!utzoo!dciem!nrcaer!xios!greg (Other paths will undoubtably work too - your mileage will vary)
davidsen@steinmetz.UUCP (06/01/87)
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.
By the way... 2.2U??? We just got 2.2L and were told that it was the
latest version. Then again that was a week ago.
--
bill davidsen (wedu@ge-crd.arpa)
{chinet | philabs | sesimo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -meneighorn@qiclab.UUCP (06/10/87)
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. > >By the way... 2.2U??? We just got 2.2L and were told that it was the >latest version. Then again that was a week ago. >-- > bill davidsen (wedu@ge-crd.arpa) The 'U' refers to the unlimited license for serial drivers. The 'L' refers to a limitation on the number of installable serial drivers. The problem with the serial port at 9600 baud is strange. 'qiclab' was busy running...er..msdos (ok I said it) for a week, and I was ~150 cmds behind from my news feed. I got permission to cart my '386 down to the VAX room, and proceeded to get over 6 megs of news and mail in the next couple hours. No 'double panics' or anything. Under what conditions were your 9600 baud problems occurring? It would be nice to get these double panic causes nailed down. Thanks in advance. -- Steven C. Neighorn tektronix!{psu-cs,reed}!qiclab!neighorn Portland Public Schools "Where we train young Star Fighters to defend the (503) 249-2000 ext 337 frontier against Xur and the Ko-dan Armada"
dave@micropen.UUCP (06/12/87)
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
greg@xios.XIOS.UUCP (Greg Franks) (06/19/87)
In article <354@micropen> dave@micropen.UUCP writes: >"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, ... Bell Technologies puts out a very nice QIC tape unit for the PC. The controller takes a full slot. The drive itself fits in a disk bay. You can also get outboard QIC drives. They supply drivers for both Microport System V and XENIX (SCO - perhaps others as well). Bell Technologies also has a super deluxe streaming version of tar which makes tapes quite quickly (at least compared to the stock version of tar on microport). We are merrily 'tar'ing files twixt the PC's that we have and CT mitiframes (68020's) with no problems what-so-ever. For Microport, you will require the link kit. Installation is painless. Their address is... Bell Technologies Incorporated 44846 Osgood Road Freemont, California. ** disclaimer ** I am a happy customer. These opinions are my own. Blah blah blah. -- Greg Franks (613) 725-5411 "Vermont ain't flat" {net-land}!utzoo!dciem!nrcaer!xios!greg (Other paths will undoubtably work too - your mileage will vary)
philip@axis.fr (Philip Peake) (06/20/87)
In article <6102@steinmetz.steinmetz.UUCP>, davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) writes: > > By the way... 2.2U??? We just got 2.2L and were told that it was the > latest version. Then again that was a week ago. The U and L suffixes relate to the number of users: L - Limited (to two users) U - Unlimited !#C!#C!4
rcw@qetzal.UUCP (sysop) (06/25/87)
In article <318@xios.XIOS.UUCP>, greg@xios.XIOS.UUCP (Greg Franks) writes: | In article <354@micropen> dave@micropen.UUCP writes: | >"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, ... | | Bell Technologies puts out a very nice QIC tape unit for the PC. The | controller takes a full slot. [...] You | can also get outboard QIC drives. | This is all very well and good, but why does it cost $2500? If Microport and Bell Technologies have a business relationship, why would Microport kill that by supporting inexpensive tape drives? Robert C. White, Jr. Graphics Information, Inc. **************** UUCP: ihnp4!upba!qetzal!rcw isis!qetzal!rcw * OIL/GAS/LAND * USPS: 3067 Robin Way, Denver, CO 80222 * CARTOGRAPHY * ATT : +1 303 759-3666 ****************
aryeh@eddie.MIT.EDU (Aryeh M. Weiss) (06/26/87)
Keywords: In article <149@qetzal.UUCP> rcw@qetzal.UUCP (sysop) writes: >In article <318@xios.XIOS.UUCP>, greg@xios.XIOS.UUCP (Greg Franks) writes: >| In article <354@micropen> dave@micropen.UUCP writes: >| >| Bell Technologies puts out a very nice QIC tape unit for the PC. The >| controller takes a full slot. [...] You >| can also get outboard QIC drives. >| > >This is all very well and good, but why does it cost $2500? If >Microport and Bell Technologies have a business relationship, why >would Microport kill that by supporting inexpensive tape drives? > Microport now has (at least at beta stage) drivers for the QIC-02 controller (eg Everex Excell). If we get them and they work I will post it. They plan to charge a nominal update fee, so you will have backup for about $900 (less if you get a QIC-36 Archeive drive). I heard that Bell Tech. doctors a ROM on the controller so that their driver only works with the controllers that THEY sell. Buyer beware... -- aryeh@eddie.mit.edu mit-eddie!lees-rif!aryeh
chapman@fornax.uucp (John Chapman) (06/26/87)
> > In article <149@qetzal.UUCP> rcw@qetzal.UUCP (sysop) writes: > >In article <318@xios.XIOS.UUCP>, greg@xios.XIOS.UUCP (Greg Franks) writes: > >| In article <354@micropen> dave@micropen.UUCP writes: > >| > >| Bell Technologies puts out a very nice QIC tape unit for the PC. The > >| controller takes a full slot. [...] You > >| can also get outboard QIC drives. > >| > > > >This is all very well and good, but why does it cost $2500? If > >Microport and Bell Technologies have a business relationship, why > >would Microport kill that by supporting inexpensive tape drives? > > > Microport now has (at least at beta stage) drivers for the QIC-02 > controller (eg Everex Excell). If we get them and they work I will > post it. They plan to charge a nominal update fee, so you will have > backup for about $900 (less if you get a QIC-36 Archeive drive). > Does anyone know which of the popular tape units have a full AT interface? I took a look at an Archive unit the other day but it is a PC interface card so you only get dma to the 1st mb of memory which as far as I can tell means your driver will have to set up buffers in low memory then copy the data from the existing buffer(s) before initiating the transfer. Aside from being messy it seems like the extra overhead will make it less likely that you will be able to keep the drive streaming. Does the (Archive) QIC-36 above refer to the tape format (or something else) or is it an alternative to the QIC-02 interface? Is the Everex Excell the same as the Everex stream60 drives I see advertised in magazines for about $700? I have called Microport to see just which drives they plan to support but all they could tell me were that they were Everex and Archive drives - I wanted model numbers so I could get one now and know that it would be compatible with whatever driver they eventually release. Why do I want one before they release a driver? Because it could be a long time before they do release it - I would rather spend my time trying to write my own driver than backing up 100mb of disk to floppies. At worst I would have to wait until they can make doscp write to the hard disk properly and then I will just use a 20 mb dos partition and do tar files to be backed up | doscat ; boot dos ; backup file; reboot unix ugly but still better than floppies. Any help would be appreciated. john ...{seismo,watmath,uw-beaver}!ubc-vision!fornax!bby-bc!john *** REPLACE THIS LINE WITH YOUR MESSAGE *** -- {watmath,seismo,uw-beaver}!ubc-vision!fornax!sfulccr!chapman or ...!ubc-vision!sfucmpt!chapman
jl@fornax.uucp (JL) (06/28/87)
We are using a Kennedy 60 MByte cartridge-system 'Superkit' from Semad Computer Products on an AT. It does not have a 'full AT' interface, but it can back up 20 MBytes (all that we currently have on the hard disk) in about 3 or 4 minutes in an 'Image' type backup. The drive keeps streaming all the time. The cost was somewhere near $1000.00 (Canadian) in February 1987. It comes with an excellent menu-driven backup/restore program. It is an internal unit. -- Jay-El
ron@vsedev.UUCP (06/29/87)
In article <149@qetzal.UUCP> rcw@qetzal.UUCP (sysop) writes: +----- |In article <318@xios.XIOS.UUCP>, greg@xios.XIOS.UUCP (Greg Franks) writes: || In article <354@micropen> dave@micropen.UUCP writes: || >"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, ... || || Bell Technologies puts out a very nice QIC tape unit for the PC. The || controller takes a full slot. [...] You || can also get outboard QIC drives. || | |This is all very well and good, but why does it cost $2500? If |Microport and Bell Technologies have a business relationship, why |would Microport kill that by supporting inexpensive tape drives? +----- What costs $2,500? Bell's tape unit w/software to drive it for SCO Xenix, and Microport UNIX is only a little over $1,000. BTW this unit works under DOS as well for those of you that have a DOS partition or an extra fixed disk. -- ron@vsedev.VSE.COM (Ron Flax) UUCP: ..!seismo!vsedev!ron INET: vsedev.VSE.COM!ron@seismo.CSS.GOV
al@tipnis.UUCP (Alfonso J. Marmora) (07/05/87)
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. > Under what conditions were your > 9600 baud problems occurring? It would be nice to get these double panic > causes nailed down. Thanks in advance. I have my Microport system polling a HP-9000/500 on port tty0. Port tty1 is unused, uucico and a shell are the only processes running. At 9600 baud, the system crashes with a "Double panic: tss fault" after about 10 minutes into the file transfer (consistently). I tried both the standard kernel and the "large" kernel with versions 2.2.2L and 2.2.2U with the same results. The problem has not (yet) occurred at lower baud rates. -- Al Marmora Tipnis Software Systems Manager Systems Software/Hardware 10815 Indeco Drive cbosgd!{syrano,mddc}!tipnis!al Cincinnati, OH 45241 (513) 791-3805