donaldg@Stardent.COM (Donald Gale) (01/24/91)
We've got 2 vt100 bugs for OS 10.2. These occur on 3000's and 3500's. 1. vt100 will come back with "cannot create vt100 window" as a message. This message is the same as if you tried to execute vt100 from a window in which you have crp'd onto a node. When the node in question was rebooted, vt100 proceeded to work normally for a day - then the same problem reappeared. 2. vt100 will appear to work, but the cursor appears over the $ prompt. Nothing can be typed into the vt100 window - dm claims that it is read-only. Has anyone else had similar problems ? Does anyone have a work-around solution ? Don Gale donaldg@stardent.com (508) 287-0100 x 268
system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (01/25/91)
In article <1991Jan23.162913.132@Stardent.COM> donaldg@Stardent.COM (Donald Gale) writes: >We've got 2 vt100 bugs for OS 10.2. These occur on 3000's and 3500's. > >1. vt100 will come back with "cannot create vt100 window" as a message. >This message is the same as if you tried to execute vt100 from a >window in which you have crp'd onto a node. When the node in question >was rebooted, vt100 proceeded to work normally for a day - then the >same problem reappeared. > >2. vt100 will appear to work, but the cursor appears over the $ prompt. >Nothing can be typed into the vt100 window - dm claims that it is read-only. > >Has anyone else had similar problems ? Does anyone have a work-around solution ? 1. We have had that problem ever since SR10.2/SR10.2.p and it is still broken in SR10.3.p. In our case you get 1 shot at vi/more/whatever that uses vt100/vtserver, then all future commands just hang. 2. Haven't seen this. The workaround is to rebuild the pty's with mkdev, but this must be done by root. The way we avoid this problem is to run X Windows, but that leaves 2 DN580's sitting useless (since last April) since X is sooooooo slow on those nodes (takes 5 minutes to login). This should be added to the FAQ, since it looks like it isn't fixed at SR10.3 either! -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775
krowitz@RICHTER.MIT.EDU (David Krowitz) (01/25/91)
My work around for vt100 bugs has been to kill the copy of /com/vt100, kill the copy of "vt100_server" (which is automatically started the first time you run /com/vt100), and then to rebuild the node's pseudo-ttys with the command "/etc/mkdev /dev pty". This seems to the fix for most wedged client/server programs that are not NCS related. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
wjw@ebr.eb.ele.tue.nl (Willem Jan Withagen) (01/25/91)
In article <1991Jan23.162913.132@Stardent.COM> donaldg@Stardent.COM (Donald Gale) writes: >We've got 2 vt100 bugs for OS 10.2. These occur on 3000's and 3500's. > I've got a few more. First of all, I think that the vt100 server uses /dev/ttyp9. Why: Because when I change the rights of ttyp9 to say root.tty 660 my user start to complain that they can't run rn, can't use vi and more of these things which use vt100 emulation. leaving them to be root.staff makes it work. But then things like write don't really work. Furthermore can this cause corrupt pty's, there's a lot of fixes for it. But still the best remedy for all is to have cron recrated all pty's in the morning. :{ Also once set to root.tty they do not stay like that for long. Once the owner of the tty is set by login and then after the user has logged off the rights are returned to root.staff :{ But I would like to have the 'std'-unix group tty to be group for all these type of things. Willem Jan Withagen Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl Digital Systems Group, Room EH 10.10 BITNET: ELEBWJ@HEITUE5.BITNET P.O. 513 Tel: +31-40-473401 5600 MB Eindhoven The Netherlands
troy@plod.cbse.unsw.oz.au (Troy Rollo) (01/28/91)
This problem has existed for quite some time, and is caused, largely, by the insistance of the vt100 emulator to use the same pty every time - if it gets mangled, you can't use vt100 anymore. A dirty fix, is to get a copy of a terminal emulator I wrote in '89, which was posted to comp.sources.misc (I think), under the title "vt100 emulator" or something similat, even though it emulates a custom terminal design, rather than a vt100. This program keeps searching through ptyp0-ptypf for one that works. That was a primitive version of the program. I had another, far more advance version ready for release which was annihilated due to a gross misunderstanding (and the whole campus knew about it that day!), so you will probably want to improve ont it (I only use the machines remotely now, so it has no interest to me).In particular, you will probably want it to search q0-qf too. ___________________________________________________________ troy@mr_plod.cbme.unsw.oz.au Fascist comments deleted for the duration of the Gulf Crisis