alen@cogen.UUCP (Alen Shapiro) (09/24/87)
In article <2419@drivax.UUCP> braun@drivax.UUCP (Kral) writes: > >After rebooting and recreating the situation, I tried to kill the daemon >manually with kill -9. It just won't die. So what's an admin to do? > 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!!!! The same problem has bitten us with a DTR race condition on modem connections. If carrier is lost and garbage on the line causes the tty line to enter ^S state (during a tip to the tty (cua) line) then tip will fail to fully exit with ~. and an unkillable tip zombie is the result. Fix here (since modem control is harder to fudge with a spare tty) is either to reboot or find someone capable of patching the kernel tty state!!! Does ANYONE have a better solution please? --alen the Lisa slayer (it's a long story) ...seismo!esosun!cogen!alen
karl@tut.cis.ohio-state.edu (Karl Kleinpaste) (09/25/87)
alen@cogen.UUCP writes:
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!!!!
The reason for this race condition is due to the fact that the tty
driver is trying to close as the process exits. Closing the tty
implies that its output q must be drained first. Hence, if the output
q drain is prevented by a TTSTOP state with ^S, the close will not
complete.
A proper solution to this problem is to set a timeout for the close to
complete, preferably in proportion to the number of characters waiting
to be drained and the speed in use on the line; if the timeout
expires, force the tty to flush rather than drain, and allow the close
to complete. I was going to do this once in a SysIII PDP-11, had it
all ready to test and integrate, but never actually finished the job.
--
Karlmitch@stride1.UUCP (10/02/87)
In article <366@cogen.UUCP> alen@cogen.UUCP (Alen Shapiro) writes: >In article <2419@drivax.UUCP> braun@drivax.UUCP (Kral) writes: >> >>After rebooting and recreating the situation, I tried to kill the daemon >>manually with kill -9. It just won't die. So what's an admin to do? >> Rebooting? Is this a power up type reboot? If not a powerup reboot the UART init routines need to be looked at. Some drivers may make some silly assumptions about the state of the hardware. Yet some UARTS are silly and little can be done. Don't forget that the problem may be with the printer. > >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. Check your system to see if this is for you. Check owner and permissions of the device. Good luck, ------------------------------------------------------------- /* * 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); } Thomas P. Mitchell (mitch@stride1.Stride.COM) Phone: (702) 322-6868 TWX: 910-395-6073 MicroSage Computer Systems Inc. a Division of Stride Micro. Opinions expressed are probably mine.
alen@cogen.UUCP (10/02/87)
>>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