cckba@iceman.jcu.oz (Kent Adams) (12/19/89)
Problem: Terminals lockup when running with 8MB RAM but not with 4MB RAM. The system is ICL PWS386 with SCO XENIX V2.3.2 plus a 16 port ANVIL Stallion board which is configured with 6 VDU's and 6 printers. After 20-30 mins of processing each VDU locks up - NO RESPONSE or display to keyboard entries. The ANVIL program "SIOMON" displays "RX" responses to keyboard "ENTER" key on the locked VDU. The commands "ps -a" or "who" do not display or know of any processing by the locked VDU. Memory and motherboards have been replaced. The system has no problems with only 4MB RAM. Kent Adams cckba@iceman.jcu.oz James Cook University of North Queensland, Townsville, Australia
kabra437@pallas.UUCP (Ken Abrams) (12/20/89)
In article <472@iceman.jcu.oz> cckba@iceman.jcu.oz (Kent Adams) writes: > >Problem: Terminals lockup when running with 8MB RAM but not > with 4MB RAM. Don't know what the difference in the amount of core memory has to do with the situation but your problem closely parallels a problem I have been having with my Xenix set up. My hardware is entirely different (AT&T 6386 w/4 meg and a CTC ports board) so I doubt that it is really hardware dependent. My terminals were locking up at various random intervals and at times, when one went the others would follow shortly. I don't have a good solution (in my situation) but I have discovered several interesting things that may be of some help to you. I was running my terminals at 9600. I have found 2 things that will eliminate the problem for me. The first is to set a parameter on the terminals to limit the transmit speed (available on VT220, maybe not on others). This option, unfortunately, is not available on the terminals I am using. Setting the speed down to 2400 also seems to eliminate the problem for me (running this way now but not happy with it). In my case, it was keys that send character sequences (like the arrow keys that send ESC sequences) that caused the lock-up. I have been trying to blame the ports board, the drivers or the application program I am running, all to no avail. I am beginning to think it is a bug in SCO Xenix (I am on 2.2.3). BTW in the process of experimenting, I have found that killing the lowest child process assigned to a terminal will "free it up" again. This is not too practical since my application then gets rather confused about what is going on and I have to kill everything. In some cases, this test could be rather dangerous. I have had data files corrupted when I disconnect the terminals or otherwise log them off unnaturally. I am about ready to prod SCO with this problem. I took it to them rather informally about 6 months ago and they pleaded ignorance. I saw another comment on here about a week ago that was similar to this but I let it get away from me. If we could assemble some data amongst us, maybe SCO would be more responsive. I have (generally) been very pleased with their tech support in the past. Call me if you like. Office number is 217-753-7965.