mp@andante.att.com (Mark Plotnick) (10/26/90)
One person here who wants absolute stability in his computing environment reluctantly had his 4MB Sun-3/75 upgraded from SunOS 3.2 to SunOS 4.0.3 (another manager wanted to retire the OS 3.2 fileserver). He is now pissed off because his typeahead is being flushed when the 'stty', 'more', and 'vi' commands are run (his objection to vi is that typein after ZZ is flushed). He said this never happened before, and accuses Sun of changing the UNIX interface he's used for 15 years, and he wants us to fix this. Maybe the problem is caused by ioctls that have changed. Maybe the increased slowness of OS 4.0 on memory-poor systems causes more of a delay in process creation and exit, and this just exacerbates the race condition that he's been toying with all these years. We're prepared to either rebuild the user-level programs he objects to, or make patches to the kernel. Can anyone tell me, in SunOS 4.0.3 (and 4.1, which we may receive for our psra server any week now) which ioctl's flush typeahead and which don't, and how we might patch the kernel to disable implicit tty flushing? Mark Plotnick allegra!mp or mp@allegra.att.com
ag@cbmvax.commodore.com (Keith Gabryelski) (10/27/90)
In article <43727@andante.att.com> mp@allegra.att.com (Mark Plotnick) writes: >One person here who wants absolute stability in his computing >environment reluctantly had his 4MB Sun-3/75 upgraded from SunOS 3.2 to >SunOS 4.0.3 (another manager wanted to retire the OS 3.2 fileserver). He >is now pissed off because his typeahead is being flushed when the >'stty', 'more', and 'vi' commands are run (his objection to vi is that >typein after ZZ is flushed). He said this never happened >before, and accuses Sun of changing the UNIX interface he's used for 15 >years, and he wants us to fix this. >Maybe the problem is caused by ioctls that have changed. Maybe the >increased slowness of OS 4.0 on memory-poor systems causes more of >a delay in process creation and exit, and this just exacerbates the race >condition that he's been toying with all these years. He is complaining about the twiddle ICANON flushing problem that was added to ldterm. There was a patch from me sent to comp.unix.internals a couple or three weeks ago to remove this feature, although some (a well respected net.type) feels the flushing is the correct behavior. I will send you the patch if you like. Pax, Keith
rcomr@koel.co.rmit.oz (Mark Rawling) (10/29/90)
ag@cbmvax.commodore.com (Keith Gabryelski) writes: >In article <43727@andante.att.com> mp@allegra.att.com (Mark Plotnick) writes: >>One person here who wants absolute stability in his computing >>environment reluctantly had his 4MB Sun-3/75 upgraded from SunOS 3.2 to >>SunOS 4.0.3 (another manager wanted to retire the OS 3.2 fileserver). He >>is now pissed off because his typeahead is being flushed when the >>'stty', 'more', and 'vi' commands are run (his objection to vi is that >>typein after ZZ is flushed). He said this never happened >>before, and accuses Sun of changing the UNIX interface he's used for 15 >>years, and he wants us to fix this. >>Maybe the problem is caused by ioctls that have changed. Maybe the >>increased slowness of OS 4.0 on memory-poor systems causes more of >>a delay in process creation and exit, and this just exacerbates the race >>condition that he's been toying with all these years. >He is complaining about the twiddle ICANON flushing problem that was >added to ldterm. >There was a patch from me sent to comp.unix.internals a couple or >three weeks ago to remove this feature, although some (a well >respected net.type) feels the flushing is the correct behavior. >I will send you the patch if you like. >Pax, Keith Is this related to the following complaint I posted to comp.sys.sun last week (which hasn't appeared yet, if ever). I'll leave the dbx stuff in in case anyone knows what gives there too. ========================================================================= Could someone _please_ comment on the following bugs (ie are they known? have they been fixed? will they be fixed? does anyone give a damn? etc):- (SS1+, SunOS4.1, X windows) (1) dbx `use' is broken:- (dbx) use a b c (dbx) use c b a Wrong order! Can have nasty consequences when searching for files. (2) dbx `up' and `down' are broken up (and less commonly down) report the wrong line number (3) csh % set filec (causes the bug) % set ignoreeof (saves you from the consequences of the bug) % vi (in vi - :map #1 :w^M^Z ie write out the file and suspend) (in vi - hit F1 and any other key close together eg F1x) Stopped % Use "logout" to logout. % The extra character (x) gets swallowed and the shell gets an EOF. This is _really_ annoying 'cause I used to use this function mapping all the time, until SunOS4 came along and stuffed up csh (and dbx). NB this doesn't just happen in vi - less does it too, but it has to be made to work, eg swap it out first. Perhaps it's related to curses or more likely anything that plays with terminal modes. Of course, if you don't set ignoreeof, your window just disappears on you. I used to think my randomly vanishing windows was some horrible X bug, but the truth is now revealed. I trust someone with some responsibility will have the decency to give a meaningful reply to this article ;-). ============================================================================ Mark Rawling, CSIRO Division of Information Technology, High Performance Computation Group, c/o Royal Melbourne Institute of Technology, email: rcomr@koel.co.rmit.oz{.au}, phone: (+ 61 3) 660 2726
jef@well.sf.ca.us (Jef Poskanzer) (10/30/90)
In the referenced message, rcomr@koel.co.rmit.oz (Mark Rawling) wrote: }(SS1+, SunOS4.1, X windows) } % set filec (causes the bug) } % set ignoreeof (saves you from the consequences of the bug) } % vi } (in vi - :map #1 :w^M^Z ie write out the file and suspend) } (in vi - hit F1 and any other key close together eg F1x) } Stopped } % } Use "logout" to logout. } % } }The extra character (x) gets swallowed and the shell gets an EOF. I ran into this problem when SunOS4.1 first came out. Turns out it's caused by running 4.0.3 binaries, perhaps off a file server that hasn't been upgraded yet. Bring your whole installation up to spec and the problem should go away. Obligatory whines: It's too bad Sun can't make their releases binary compatible. It's too bad comp.sys.sun's turnaround is so slow that it's useless for debugging. --- Jef Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef "And gladly wolde he lerne, and gladly teche." -- Geoffrey Chaucer
guy@auspex.auspex.com (Guy Harris) (10/31/90)
>There was a patch from me sent to comp.unix.internals a couple or >three weeks ago to remove this feature, although some (a well >respected net.type) feels the flushing is the correct behavior. I wouldn't entirely agree with the aforementioned well-respected net.type; as indicated, in my view the *ideal* would probably be to use M_READ notification *if that doesn't break 'poll()'* and have data not be sent upstream in uncooked mode until it's requested. SunOS 4.x doesn't have M_READ; S5R4 does, but I don't know if it works with "poll()". The main point in my postings was that the flushing *was* stuck in for a reason, and that if it's taken out the person taking it out should either be prepared to have the undesirable behavior removed by the flushing reappear, or add in more stuff to keep that behavior from reappearing....
ted@arsocomvax.socom.mil (Ted Nolan) (11/01/90)
It sounds like you are running into a problem I found on 4.0.3. We have an application that drives a terminal window by essentially "stuffing" into it. I had modified the "less" pager program to use a nonflushing IOCTL to return to terminal to cooked mode from cbreak mode, so that our application could stuff something like q^Uunix command The intent was that if the pager was active, the 'q' would exit it, and then the unix command would start. (If the pager were not active, the ^U would erase the 'q', and the command would still be ok). This worked fine under SunOS 2.X and 3.X, but in 4.0.3 the ioctl (TIOCSETN (bsd) == TCSETS (sysV)) that is documented NOT to flush the input actually does flush it, and our application doesn't work. Whether or not this is "good" in some abstract sense, is, I suppose, debatable. However, it does not work as documented, which seems clearly wrong to me. Here's the response I got back from sun: > > deleted stuff > >In looking this over it looks like you are running into a problem under >4.0 and later, when things were switched over to STREAMS. The bugid >that you are running into is 1007731. The problem turns out to be, that >when the mode of the tty changes to between ~CBREAK and CBREAK, an >automatic flush (M_FLUSH) occurs. In your example, you will see, that >if you comment out the ORing of the CBREAK flag, the TIOCSETN will work >correctly as you indicated. From the bug report this looks like this >will be fixed in 4.1 (the next release). > This doesn't really help, because I need CBREAK to ~CBREAK transitions. Am I to gather this is still not fixed in 4.1? Ted Nolan ted@usasoc.soc.mil PS: One weird workaround I found... Do an rlogin localhost in the window you want this to work in, and most of the time it will.
per@erix.ericsson.se (Per Hedeland) (11/06/90)
In article <1990Oct31.212012.13776@usasoc.soc.mil> ted@arsocomvax.socom.mil (Ted Nolan) writes: |>worked fine under SunOS 2.X and 3.X, but in 4.0.3 the ioctl (TIOCSETN |>(bsd) == TCSETS (sysV)) that is documented NOT to flush the input |>actually does flush it, and our application doesn't work. |>Am I to gather this is still not fixed in 4.1? As far as I can determine, the flushing of input that, contrary to documentation, happened when TIOCSETN changed to/from CBREAK mode in 4.0.3, is indeed fixed in 4.1, i.e. input does *not* get flushed. I have not tested what happens when using the termio interface, though. --Per Hedeland per@erix.ericsson.se or per%erix.ericsson.se@uunet.uu.net or ...uunet!erix.ericsson.se!per
guy@auspex.auspex.com (Guy Harris) (11/08/90)
>As far as I can determine, the flushing of input that, contrary to >documentation, happened when TIOCSETN changed to/from CBREAK mode in 4.0.3, >is indeed fixed in 4.1, i.e. input does *not* get flushed. I have not tested >what happens when using the termio interface, though. TIOCSETN uses the "termio" interface (read TTCOMPAT(4M)).