manes@dasys1.UUCP (09/05/87)
I've heard rumblings for some time that Microport has some troubles supporting 9600 baud, the usual complaint being that it loses characters. I've been porting Magpie (my BBS program) to Unix from MSDOS and have been testing it with a 9600 baud terminal and null modem line to tty0 (ttyM0). What I've learned from several months of this is that while Microport can handle 9600 baud under light i/o with little problem, sustained output from a 9600 baud terminal, even the relatively short blocks of Forsberg's YMODEM, is severely corrupted. At worst, it can crash Unix and leave you staring at the dreaded "double panic:" error that means pulling the plug and restarting. To test this phenomenon, try running a 'cat > filename' from a 9600 baud computer (not dumb terminal) and dumping a fairly large text file to Unix. I spent an hour trying to transfer a large (1 meg) file from an MSDOS AT running Procomm to Unix. After a dozen aborts, and three complete crashes, I finally transferred the file successfully with Xmodem (Forsberg's 'rz'). This week, I've been writing Magpie's protocol up/download module. I had never gotten Ymodem to run reliably at 9600 baud on Microport and so figured the available PD file transfer utils with Ymodem must be brain-dead, at least for V/AT. Xmodem worked fine. So did my Xmodem. I tested it about two dozen times, simulating line noise and sync errors by sending the receive process messages during file transfer. No problem. Then I increased block size to 1024 (for Ymodem). Curses!... I couldn't get even a single block to transfer successfully. I spent a good 48 hours tearing my code apart, retesting (and rebooting) and couldn't lick the problem. Then I downshifted the remote terminal to 2400 baud and, voila, Ymodem worked! So I added some logging tags to the program to see what the hell was going on with Unix at 9600 baud and found that entire blocks of the transferred text were being scrambled when read by the receiver. Some blocks were missing; some were inverted. This leads me to believe that the internal buffering is somehow overflowing or otherwise confusing Unix. o I know the remote AT works fine at 9600 baud. I routinely null-modem large files between it and an XT. o The Unix box is a 10 mHz AT running a pair of 16450 UARTs. Microport version is 2.2.U. o Through the >same< code block, Xmodem works fine. Increasing the sending block to 1024 bytes generates the problem. Have any Microport users experienced similar problems? +---------------------------------------------------------------------------+ | Steve Manes (NYC) !ihnp4!{pur-ee|iuvax}!bsu-cs!zoo-hq!magpie!manes | | Roxy Recorders, Inc. (multitrack recording) | | Magpie BBS Develop. (UNIX/MSDOS 212-420-0527) | +---------------------------------------------------------------------------+
wietse@eurifb.UUCP (09/07/87)
In article <1198@dasys1.UUCP>, manes@dasys1.UUCP (Steve Manes) writes: > [reading garbage at 9600 baud when ymodem block size is increased to 1k] I had a similar problem when increasing the size of writes to floppy from 512 bytes to 1k (it was a small program that sits in a pipeline with tar and asks for a new floppy at the appropriate time). Tar will complain when the archive is read (directory checksum errors). There are no problems with 512-byte writes. The version we are running is 2.2 L. Wietse Venema (uucp: ...!mcvax!eutrc3!wswietse bitnet: wswietse@heithe5)
jmsully@suprt.UUCP (09/21/87)
In article <207@eurifb.UUCP>, wietse@eurifb.UUCP (Wietse Venema) writes: > In article <1198@dasys1.UUCP>, manes@dasys1.UUCP (Steve Manes) writes: > > [reading garbage at 9600 baud when ymodem block size is increased to 1k] > > I had a similar problem when increasing the size of writes to floppy from > 512 bytes to 1k (it was a small program that sits in a pipeline with tar > and asks for a new floppy at the appropriate time). Tar will complain > when the archive is read (directory checksum errors). There are no problems > with 512-byte writes. As of September 22, 1987 this bug had not been reported to us. We have a program which we use in-house which writes to the floppy in ~60K chunks and we do not have a problem with this. It may also be possible that this is a problem with tar, you might try using the block factor (b) option to read the disk. Also make sure that you are using the raw device when you read and write the diskette. Please send us further details and, if possible, the code which reveals this problem.
jmsully@suprt.UUCP (John M. Sully) (09/22/87)
In article <1198@dasys1.UUCP>, manes@dasys1.UUCP (Steve Manes) writes: > I've heard rumblings for some time that Microport has some troubles > supporting 9600 baud, the usual complaint being that it loses characters. > [...] > At worst, it > can crash Unix and leave you staring at the dreaded "double panic:" > error that means pulling the plug and restarting. We have been aware of this problem for some time now and have been working to fix it. It appears that the problem will be fixed in the 2.3 release which is due out sometime in October. If you have purchased a support contract you will receive notice of this upgrade in the mail from us, if not, please contact the support department in mid-October for details on how to obtain this upgrade. John M. Sully Microport Systems Technical Support
allbery@ncoast.UUCP (Brandon Allbery) (09/29/87)
As quoted from <105@suprt.UUCP> by jmsully@suprt.UUCP (John M. Sully UUCP: ...!{sun | ucbvax | ihnp4}!amdcad!uport!techs):
+---------------
| In article <207@eurifb.UUCP>, wietse@eurifb.UUCP (Wietse Venema) writes:
| > I had a similar problem when increasing the size of writes to floppy from
| > 512 bytes to 1k (it was a small program that sits in a pipeline with tar
| > and asks for a new floppy at the appropriate time). Tar will complain
| > when the archive is read (directory checksum errors). There are no problems
| > with 512-byte writes.
|
| It may also be possible that this is a problem with tar, you might try
| using the block factor (b) option to read the disk. Also make sure that
| you are using the raw device when you read and write the diskette.
+---------------
This probably *is* a problem with tar. I've had problems with some systems
reading from a zcat | tar xf - pipeline, which goes away if I uncompress
the input file and say tar xf filename. I infer that the "blocksize" on a
pipe is widely variable, at least with zcat on the other end, and tar therefore
hangs on strangely-shaped blocks. (Most recent system this occurred on was a
3B1; I've had it happen on Plexus and Altos as well, so I suspect it's a
problem with tar itself. Not just the AT&T version, either; Altos uses the
BSD version.
--
Brandon S. Allbery, moderator of comp.sources.misc
{{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery
ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY
<<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>>
"Mummy, what's an opinion?"