kenyon@uicbert.eecs.uic.edu (11/30/89)
Is there a problem with telnetd on 3.2? I have ksh88 running on my 4D/120GTX under 3.2. When I login at the console all works as expected. When I login from a terminal (vt100) through ethernet I get logged out when I enter a ^C ( intr = ^C). If I change the intr to anything else, eg. ^P, when I enter that command (^P) I get logged off the system. This problem started when I changed to 3.2. If I use the same version of ksh88 on a 3.1g system (4D/20) this problem is gone. Therefore to see if it was the telnetd from 3.2 I copied the telnetd from the 3.1g system to the 3.2 system and the problem is gone. If I copy the 3.2 telnetd to the 3.1g system now that system has the same problem I had with the 3.2 system. Any Ideas? Bob Kenyon 128.248.166.25
jmb@patton.sgi.com (Jim Barton) (12/01/89)
In article <84600002@uicbert.eecs.uic.edu>, kenyon@uicbert.eecs.uic.edu writes: > > Is there a problem with telnetd on 3.2? No. > I have ksh88 running on my > 4D/120GTX under 3.2. When I login at the console all works as expected. > When I login from a terminal (vt100) through ethernet I get logged out > when I enter a ^C ( intr = ^C). If I change the intr to anything else, > eg. ^P, when I enter that command (^P) I get logged off the system. > > This problem started when I changed to 3.2. If I use the same version > of ksh88 on a 3.1g system (4D/20) this problem is gone. > > Therefore to see if it was the telnetd from 3.2 I copied the telnetd from > the 3.1g system to the 3.2 system and the problem is gone. If I copy the > 3.2 telnetd to the 3.1g system now that system has the same problem I > had with the 3.2 system. > > Any Ideas? > > > Bob Kenyon > 128.248.166.25 There were some fixes to terminal handling and such in 3.2. I'm using ksh88 right now, and log in to 3.2 systems all the time via rlogin and telnet (from terminal servers). I vaguely remember having a similar problem when first porting ksh88, so I think it's the port, not telnet. Check are that you use RAWONLY mode, I believe this may have something to do with it. Perusing the local port, the only sgi specific changes I made were 1) fixed the infinite loop bug in history.c when opening a history file, and 2) added some define's to jobs.c to make job control work. Other than that, raw mode seems to be the interesting one. -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb
arc@SGI.SGI.COM (Andrew Cherenson) (12/01/89)
In article <84600002@uicbert.eecs.uic.edu> kenyon@uicbert.eecs.uic.edu writes: > > Is there a problem with telnetd on 3.2? It's fixed in the 3.2.1 maintenance release. The 3.1F or 3.1G telnetd should suffice until then. Csh users aren't affected.
zombie@voodoo.UUCP (Mike York) (12/03/89)
In article <8912010051.AA27187@sgi.sgi.com> arc@SGI.SGI.COM (Andrew Cherenson) writes: > >It's fixed in the 3.2.1 maintenance release. The 3.1F or 3.1G telnetd should >suffice until then. > Tell me more about 3.2.1. There are two bugs that we've encountered in 3.2 that we're trying to deal with now: 1. The dial & button box does not work properly under 3.2, rendering our application next to useless for production (it doesn't impact us too much for developmenmt). The hotline says this problem is fixed for 3.3, but they haven't gotten back to us yet on what to do to fix the problem for 3.2. Is the fix in 3.2.1? 2. The same source code compiles and runs fine on 3.1, but repeatedly dumps core on 3.2 (when we do a certain sequence of events). This problem was just discovered yesterday, and I'm in the process of isolating the exact cause. Some memory is getting overwritten, but we're not sure where. When I left work last night, malloc was the current *suspect*. Any clues? I know this is vague, but these kind of problems are a real bear to track down, and any pointers would be appreciated. -- Mike York | "But first, I have to satisfy Boeing Computer Services | my sense of moral outrage" (206) 234-7724 | uw-beaver!ssc-vax!voodoo!zombie | -Roger Rabbit
zombie@voodoo.UUCP (Mike York) (12/06/89)
In article <619@voodoo.UUCP> zombie@voodoo.UUCP (Mike York (that's me)) writes: > >Tell me more about 3.2.1. There are two bugs that we've encountered in >3.2 that we're trying to deal with now: I go on to tell about the dial & button not working, and a suscpected problem with malloc. Well, the dial & button box still doesn't work, but malloc is no longer suspect. I have found the bug and it is us. We were inadvertently referencing an object that had been freed. This never bit us in previous releases, but our past sins have come back to haunt us in 3.2. Now, if that D&B box would just work we'd be all set... -- Mike York | "But first, I have to satisfy Boeing Computer Services | my sense of moral outrage" (206) 234-7724 | uw-beaver!ssc-vax!voodoo!zombie | -Roger Rabbit
wiltse@oceana.esd.sgi.com (Wiltse Carpenter) (12/07/89)
In article <619@voodoo.UUCP>, zombie@voodoo.UUCP (Mike York) writes: > > 1. The dial & button box does not work properly under 3.2, rendering > our application next to useless for production (it doesn't impact us > too much for developmenmt). The hotline says this problem is fixed for > 3.3, but they haven't gotten back to us yet on what to do to fix the > problem for 3.2. Is the fix in 3.2.1? > The problem with the dial box in 3.2 has to do with the dbtext() function. If a program repeatedly calls dbtext() at a rate higher than the serial link to the dial box can sustain, dbtext() will leave a file descriptor open. This bug has been fixed internally. A work around for the problem would be stat(2) the file ``/dev/dialwarp'' which is a FIFO used to pass data from the application program to the dial daemon and check to see if it contains more than say 8K of data. If the FIFO is this full, then the application should pause until it empties. Note that each call to dbtext() results in only 12 bytes of data and the dial box serial line runs at 9600 baud so one needs to be calling dbtext() rapidly to see the failure. We will of course be fixing this bug in the next possible release, but it is not fixed in 3.2.1.