Xref: utzoo comp.unix.i386:3007 comp.unix.wizards:20638 comp.sys.att:8821
Path: utzoo!utgpu!watserv1!watmath!att!dptg!lzsc!hcj
From: hcj@lzsc.ATT.COM (HC Johnson)
Newsgroups: comp.unix.i386,comp.unix.wizards,comp.sys.att
Subject: Re: Process hanging on AT&T 6386 Sys V R3.2
Summary: This is a consequence of blocking writes
Message-ID: <1311@lzsc.ATT.COM>
Date: 16 Feb 90 21:24:49 GMT
References: <188@nimbus3.UUCP> <293@pallas.athenanet.com>
Distribution: na
Organization: AT&T BL Middletown/Lincroft NJ USA
Lines: 27

In article <293@pallas.athenanet.com>, kabra437@pallas.athenanet.com (Ken Abrams) writes:
> In article <188@nimbus3.UUCP> djs@nimbus3.UUCP (Doug) writes:
> >I'm having a problem with an AT&T 6386 running System V/386 R3.2 using
> >an AT&T IPC-802 Intelligent Ports Card.  A program has one of the
> >ports open for reading and writing.  While executing a write(2) system
> >call of more than one byte (although I'm not sure that matters),
> >something happens on the line and the process hangs.  It can't be
> >killed in this state.  A scan of the manuals reveals no useful information.

This is caused by two properties:
1. This is a blocking write, that is process is suspended until the write
   completes.
2. The driver has choses to sleep at a priority that is uninteruptable.

This is a necessary evil; uninteruptable sleeps were meant for things like
buffered IO to disk (and we know that disk never fail to complete!!) and 
interruptable sleeps allowed users to kill tty processes.  Now we have
communications activities that we dont want the user to kill at a bad time
so the sleep is not interruptable.  But since Comm lines fail in many ways,
you are left with a process waiting for a never ending sleep.  
The only solution is REBOOT.

Howard C. Johnson
ATT Bell Labs
=====NEW address====
att!lzsc!hcj
hcj@lzsc.att.com