SUMMARY: tty processes go into Disk Wait state!

From: tommy@boole.att.com
Date: Thu Mar 18 1993 - 09:07:20 CST


Way back on Feb 22, I wrote:

------- Forwarded Message

From: tommy@boole.att.com
Message-Id: <9302230313.AA01683@hoodlum.att.com>
To: Sun Managers <sun-managers@eecs.nwu.edu>
Subject: tty processes go into Disk Wait state!
Date: Mon, 22 Feb 93 22:13:36 -0500

Oh God this is much worse than my console problem. I have some
processes that go into disk wait state. One is a getty, but no big
deal since I don't need that line. The killer is when my sole port
used for outgoing uucp suffers from this. I have to reboot the system
since disk-wait processes don't listen to signals.

Please send suggestions. The system is a 3/180 with an ALM-2 board
with 16 ports. It runs SunOS 4.1.1.

Tommy Reingold
AT&T Bell Labs, Holmdel, NJ
tommy@boole.att.com or att!boole!tommy

------- End of Forwarded Message

Someone said I should try power-cycling the modem. I'm using hardwire
lines. I suppose I could have tried removing and reinserting the
cables.

I got a call from someone at Sun because someone else at Sun had
brought my sun manager message to his attention. Yes, you read that
right, folks! He recommended applying patch 100315-02 which
specifically mentions tty problems and also patch 100359-06 which is a
jumbo streams patch.

Actually, the problem went away soon after I posted my message, but the
guy at Sun really wanted me to install these patches and since I've
done so, I have not had the problem. Of course, that doesn't prove the
patches worked but they haven't made things worse.

Hal Stern said:

$ find out what they're hanging on -- run adb and do a $<traceall
$ to see if they're stuck in streams code (ldtermclose, or
$ something like it). if so, there are a few streams/serial
$ line patches to 4.1.1 that fix flow control and shutdown
$ problems with serial lines, particularly with ALM-2 ports

Perry Hutchison corrected my use of the term "disk wait" thusly:

$ Actually, when ps reports the state of a process as D, it means that
$ the process is in a non-interruptible wait, which the manpage describes
$ as "typically short-term waits for disk or NFS I/O." The D is perhaps
$ better thought of as representing "Device" or "Driver" rather than
$ "Disk", as the wait can involve any driver (and probably a few other
$ things as well, however things which stay in D longer than a fraction
$ of a second are almost always hung up in some driver somewhere).

(What were the chances that two people named Perry would answer my
call?)

Thanks to:

"Jim Davis" <jdavis@cs.arizona.edu>
stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)
Jim Davis <jdavis@cs.arizona.edu>
pmetzger@shearson.com (Perry E. Metzger)
Perry_Hutchison.Portland@xerox.com
dewey@rtfm.sps.mot.com (Dewey Henize)
ups!kalli!kevin@fourx.Aus.Sun.COM (Kevin Sheehan {Consulting Poster Child})
ups!upstage!glenn@fourx.Aus.Sun.COM (Glenn Satchell - Uniq Professional Services)

--
Tommy Reingold
AT&T Bell Labs, Holmdel, NJ
tommy@boole.att.com or att!boole!tommy



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:36 CDT