james@osi3b2.UUCP (James R. Van Artsdalen) (09/13/86)
We recently upgraded our 3b2-300 to a 3b2-310. We were running System V.2.0 and upgraded to 2.0.4 at the same time we did the hardware upgrade. We have one serial board, and 1 megabyte of RAM. We had been running the console and three of the serial ports on the serial board at 19.2Kbps (the other two serial ports were run at 2400bps and 1200bps). With the -300 motherboard and V.2.0, this worked fine. After the upgrade, we began having trouble with the serial lines. Every so often the system would get into a mode wherein it would lose characters on the serial ports. When printing mail it would print some of the mail and stop: almost as though the character output buffers were being lost. Once the system began this there was no way to recover without rebooting. This apparently did not affect operation of the CPU itself: the system would run fine indefinitely after this started. On the basis of some rumors I've upped the NCLIST value to 200 from 80 and dropped the baud rate on the terminals to 9600bps from 19.2Kbps. The problem has not occurred in two weeks (previous frequency was about twice a week). Rumor also suggests that the problem can be fixed without rebooting by re-pumping the serial card. I have not tried this. The problem has been seen on a -310 with System V.2.1. It has not been seen on a -300 to my knowledge. The -310 running V.2.1 has only seen the problem once in a month of operation. Has anyone else seen this problem, and does anyone know what the true cause is? I am not confident that I have solved it with either change. I would like to solve this. With our -300 we ran the computer for months between reboots, but now we're restarting every couple of weeks. -- James R. Van Artsdalen ...!decvax!dartvax!osi3b2!james Live Free or Die
randy@chinet.UUCP (randy) (09/14/86)
In article <193@osi3b2.UUCP> james@osi3b2.UUCP (James R. Van Artsdalen) writes: > >After the upgrade, we began having trouble with the serial lines. Every so >often the system would get into a mode wherein it would lose characters on >the serial ports. >On the basis of some rumors I've upped the NCLIST value to 200 from 80 and >James R. Van Artsdalen ...!decvax!dartvax!osi3b2!james Live Free or Die I have a 3b2/300 with 2 megs memory, and 3 ports cards. I have two 9600 baud terminals connected to console and contty. All the ports card have 2400 baud modems on them. What you describe happens about once a week with out fail. When it happens, it happens on all ports, console included. Only way to fix is to shutdown and restart. I have played with clists from 50 to 300 with no change. It did not happen until I upgraded to 2.0.4 Another strange thing with 2.0.4 is that a number of times a day, the i/o system just *stops*! Processing continues on and characters echo at the terminals, but nothing happens. From 30 seconds to 5 minutes it just sits, then bang, every thing continues on as if nothing happened. It seems to be disk i/o related. I can be sitting at the console when it happens, look over at the modem that a uucp is going on, and watch the flow go fine for about a half minute. Then it starts timing out, as if a buffer got filled and had to go to the disk. Generally, uucp times out before the system fires back up again. By various experiments, I have found a combination of things agravate the problem. If I set NBUFS to over 300 *AND* any program is set sticky bit, it runs rampant. I have had to un sticky /bin/sh, rnews, vi and all others, or the system is unusable. Is it my 300 only, or is this common? -- .. that's the biz, sweetheart... Randy Suess chinet - Public Access UN*X (312) 545 7535 (h) (312) 283 0559 (system) ..!ihnp4!chinet!randy
jgy@hropus.UUCP (John Young) (09/15/86)
There are a number of known problems with the ports cards and software, especially when running at high speeds. Call your software support service for details. There is a new ports board out called a High Performance Ports board (it has HPP stamped on the front) which cures some of the performance problems. I was not aware of a pre/post-2.0.4 boundary to these problems.
djc@chinet.UUCP (David J. Carpenter) (09/16/86)
In article <548@chinet.UUCP> randy@chinet.UUCP (Randy Suess-) writes: >What you describe happens about once a week with >out fail. When it happens, it happens on all ports, console included. Only >way to fix is to shutdown and restart. I have played with clists from 50 to >300 with no change. It did not happen until I upgraded to 2.0.4 > Another strange thing with 2.0.4 is that a number of times a day, >the i/o system just *stops*! >Is it my 300 only, or is this common? I get that about once a week also. I have a 300, and have upgraded to 2.0.4. I haven't ever seen the i/o system just stop, though. The characters get consistently lost in big chunks. Every time you do a screen refresh, maybe every other chunk off 100 characters disappears. You can only reboot. Must be a bug in the 2.0.4 tty driver... -- ...!ihnp4!chinet!qpsn!david David Carpenter [home] (312) 545-8076 [work] (312) 787-9343
jgy@hropus.UUCP (John Young) (09/17/86)
In referrence to my response to someone's problems with lost characters on 3B2's I have been asked to withdraw my "advertisment" of the new ports board I mentioned. John Young
metro@asi.UUCP (Metro T. Sauper) (09/19/86)
I did not see the origional problem, but from the responses, it seems to sound like a problem I had on my 3B2/400. Symtoms: At all terminals including console - Characters you type would not be echoed back (i.e. not read). Repeated typing of a character might echo 1 in 10 times. When echoing occured, sometimes groups of 3 & 4 characters would go through at one time. Cause: We had a US Robotics modem connected to the contty port. The modem was set to echo characters sent from computer to pace the dialing strings. The DCD line was tied high so the 3B2 would talk to the modem. If the current user broke the connection without ^D (i.e. did not log off) the computer could not tell since the DCD line was tied high. The modem echoed DISCONNECT^m. The computer echoed DISCONNECT not found -- which was echoed back by the modem -- which was echoed back by the computer in addition to another DISCONNECT not found -- ............. Soon there is a olympic caliber event to see who will give up first, the computer or the modem. The result to the rest of the users on the system is no input buffers to read into. Solution: 1. If this happens, check to see if the transmit are recieve lights are on solid while the OH (off hook) light is out. If this is the case, turn off teh modem for a while to wait for the 3B2 to flush its buffers. Everything should come back to normal. 2. Turn of the command echo in the modem. I don't think you need it anyway. The session will still be live after the connection is broken, but after the DISCONNECT not found, the line is idle. This had caused me no end of headaches until i figured it out. Any comments on what I observed are welcome. Metro T. Sauper, Jr. ihnp4!ll1!bpa!asi!metro
james@osi3b2.UUCP (James R. Van Artsdalen) (09/21/86)
In article <17@asi.UUCP>, metro@asi.UUCP (Metro T. Sauper) writes: > > I did not see the origional problem, but from the responses, it seems to > sound like a problem I had on my 3B2/400. [description of problem] > We had a US Robotics modem connected to the contty port. The modem was set > to echo characters sent from computer to pace the dialing strings. The DCD > line was tied high so the 3B2 would talk to the modem. If the current user > broke the connection without ^D (i.e. did not log off) the computer could > not tell since the DCD line was tied high. The modem echoed DISCONNECT^m. [Description of characters echoed forever and solution to it all] > This had caused me no end of headaches until i figured it out. Any comments > on what I observed are welcome. > > Metro T. Sauper, Jr. > ihnp4!ll1!bpa!asi!metro This could be a problem, but not in this case. Our modem is set up not to echo the the characters from the computer when dialing. In addition I have a little black-box to cause the carried detect to pulse low whenever carrier is lost (about a 30 second pulse). Otherwise carried detect line into the 3b2 stays high. Fixes that incredibly annoying kernel bug in the 3b2 that prevents the 3b2 from talking to modems when carrier detect is low... -- James R. Van Artsdalen ...!ut-ngp!utastro!osi3b2!james Live Free or Die
rjk@mrstve.UUCP (Richard Kuhns) (09/22/86)
I've experienced this problem on a 3b2/310 running 2.0.4, but I have yet
to encounter it on either of our 400s (also running 2.0.4). Rebooting
has always cured it -- I haven't waited more than about 10 minutes to
see if it would disappear.
Someone (sorry, I lost the name) said that he'd experienced this problem
due to a USR modem with echo turned on. I once connected a 3b1 to one
of our 400s via a direct connection, with getty running on both ports
(oops :-) ). I did NOT experience this problem then. The system slowed
down most remarkably, but I did not loose any characters. Unplugging the
cable restored everything to normal, with no noticeable side effects.
--
Rich Kuhns {ihnp4, decvax, etc...}!pur-ee!pur-phy!mrstve!rjklarry@kitty.UUCP (Larry Lippman) (09/27/86)
In article <254@mrstve.UUCP>, rjk@mrstve.UUCP (Richard Kuhns) writes: > ... > I once connected a 3b1 to one of our 400s via a direct connection, with > getty running on both ports (oops :-) ). I did NOT experience this problem > then. The system slowed down most remarkably, but I did not loose any ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > characters. Unplugging the cable restored everything to normal, with no > noticeable side effects. I have accidently done the same thing myself, and the results are so astounding on a 3B2 that even your statement qualifies as the understatement of the year! ==> Larry Lippman @ Recognition Research Corp., Clarence, New York ==> UUCP: {allegra|decvax|rocksanne|rocksvax|watmath}!sunybcs!kitty!larry ==> VOICE: 716/688-1231 {hplabs|ihnp4|seismo|utzoo}!/ ==> FAX: 716/741-9635 {G1,G2,G3} "Have you hugged your cat today?"