Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!ucsdhub!esosun!cogen!alen
From: alen@cogen.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: tty hangs in ^S state was (Re: Killing the printer daemon)
Message-ID: <370@cogen.UUCP>
Date: Fri, 2-Oct-87 13:27:29 EDT
Article-I.D.: cogen.370
Posted: Fri Oct  2 13:27:29 1987
Date-Received: Sat, 3-Oct-87 12:09:10 EDT
References: <2419@drivax.UUCP> <366@cogen.UUCP> <684@stride.Stride.COM>
Reply-To: alen@cogen.UUCP (Alen Shapiro)
Distribution: world
Organization: Cogensys, LaJolla, Calf.
Lines: 52

>>I've had a similar problem before, the printer was on a serial
>>interface and the printer died when the line was in a ^S state.
>>The daemon process which was in an i/o pending state would not die
>>until we attached a tty and typed ^Q at it!!!!
>>
>>Does ANYONE have a better solution please?
>
>Well maybe -- On some System V derrived systems there is a system
>call (ioctl) to unblock a serial port blocked on ^s_stop.  Here
>is a quick chunk of code which clears the condition on a specific
>port.  It should be rewritten to use standard in and out and
>check for errors and such.  So far it has always been simpler to
>just recompile.
>
>/*
> * unwedge.c -- there is a race condition which can
> * have the driver hung on a ^s_stop with ^s^q (Xon/Xoff)
> * disabled. This will send an ioctl to the driver to
> * change this.
> */
>#include <sys/termio.h>
>main()
>{
>  register int fd=open("/dev/tty_port_that_is_stuck",2);
>  ioctl(fd, TCXONC,1);
>}
My thanks for this valliant attempt however I believe that the
printer daemon opens the lp port for exclusive use and while
the daemon holds the port the unwedge program will not get it.
(I have not confirmed this so please forgive me if I am wrong)

The second aspect of my problem - what happens when line noise 
on modem disconnect causes the modem ttyline to think it is in 
^s_stop state (quite frequent on our modems) causes init to 
block in it's open call. If init blocks, I suspect the above 
program will too. I think what I really need is some suid-root 
prog to do some bit twiddling in the kernel....Any ideas? 
 
oh by the way - this problem has been seen on sun/2 & sun/3 
running sun/berkeley unix (the above program DID compile
under sun sys5 compatibility mode).
 
--alen the Lisa slayer (it's a long story)
    .....seismo!esosun!cogen!alen


Now I know what FILLER lines are for
Now I know what FILLER lines are for
Now I know what FILLER lines are for
Now I know what FILLER lines are for
Now I know what FILLER lines are for
Now I know what FILLER lines are for