adnan@sgtech.uucp (Adnan Yaqub) (09/12/90)
I have a serial device driver which doesn't work on 386/ix 2.02 or Interactive Unix 2.2. However it does work on SCO Unix 3.2 and SCO Xenix 2.3.x. I have another driver (also a serial device driver) which works on all three of the above OSes with which I have used to compare my driver. I do not have kernel (especially line discipline) source code. The buggy driver exhibits the following anomalies. First, when a getty is enabled on a serial line, the getty will sometimes (often) open the line, put out the login prompt, and then close the port and die, only to be respawned by init. Soon, of course, init gets tired of respawning and complains. After several "telinit q"s one is able to get a "stable" getty and log in. Once logged in, everything seems to work except the UNIX interrupt signal (DEL key or ^C or whatever you use). When one types a DEL (or whatever) nothing happens, except the flushing of unprocessed input. On close inspection, what is happening is the following: 1) The DEL (or whatever) is delivered to ttin (aka l_input). 2) ttin does the appropriate flushes, and, I assume, sends a signal to the process group (t_pgrp). (The pgrp has been verified to be correct, at least in the driver.) 3) The ttread (aka l_read) does not return to the driver read. Neither does it return to the process (i.e., take a longjump). Further inspection reveals that the process is waiting on the rawq of the tty structure. (Which, according to my UNIX internals info is where ttcanon waits.) So, my question is what happened to the signal? Any ideas? I can't suspect an OS bug because I have a driver that works. So what have I done wrong? Thanks. -- Adnan Yaqub (adnan@sgtech.uucp) Star Gate Technologies 29300 Aurora Rd, Solon, OH, 44139, USA, +1 216 349 1860