Help me debug my driver! (A little long but very exciting.)
Adnan Yaqub
adnan at sgtech.uucp
Wed Sep 12 06:12:30 AEST 1990
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 at sgtech.uucp)
Star Gate Technologies
29300 Aurora Rd, Solon, OH, 44139, USA, +1 216 349 1860
More information about the Comp.unix.internals
mailing list