I/O to ttys has been the proximate cause of UNIX process unhappiness  
since time-immemorial. You can't kill (or swap) a process involved in  
DMA I/O (the subsequently completed I/O would then end up in some  
other process' memory, which would be ... bad), so the kernel doesn't  
permit that.

In the case of ttys, where a device (or a user!) on the other end can  
use flow control to stop the I/O for an arbitrary amount of time (an  
eternity when CPU clocks are measured in MHz/GHz), you now have a  
process waiting on that I/O to complete that otherwise can't be  
manipulated at all until I/O completion, save for manipulation in the  
most dire/dangerous ways (e.g. DDB).

If you want to watch real badness, hit ^S on a UNIX console, and wait  
a while. Depending on how many processes want to spew on the console,  
and how often, the process table will eventually fill up with  
unkillable processes, or ... zombies. This is one reason why syslogd 
(8) exists.

The described behavior could also be caused by a lost I/O completion  
interrupt.

Just out of curiosity, if you put asterisk on the back side of a pty  
(e.g. with script(1), screen(1), ssh(1), etc), does the hang still  
happen? Or is asterisk directly opening /dev/console itself?

	Erik <fair@netbsd.org>