GKN@SDSC.BITNET.UUCP (07/15/86)
[please - no flames about submitting an SPR]
I may have a handle on a possible bug in YFDRIVER. The scenario is as follows:
You have a busy port, say one which is connected to a sick modem which is
spewing forth garbage at a tremendous rate. On normal terminal ports this
will awaken JOB_CONTROL, who will in turn awaken LOGINOUT to log this port
in. LOGINOUT will eventually get tired and give up, only to be dragged right
back into memory in a few milliseconds.
I have 2 dumps where an IRP was being posted complete for a buffered read
on this login job where the byte count (IRP$L_BCNT) is FFFF, and the MOVC3
instruction at MOVBUF (in IOC$IOPOST) plus a few is dutifully trying to move
that many bytes, with, uh, less than wonderful results.
I'd send the dumps off, but I've a feeling that they wouldn't do anybody
any good because the terminal driver has long since stopped worrying about
this IRP and has gone on to bigger and better things. My theory is that
the byte count field (incidentally, IRP$L_IOST1 contains the same thing!)
is getting smashed sometime after the read has been terminated by buffer
full or read terminator but before the terminal driver decides to actually
put the packet on the I/O postprocessing queue.
Anybody else seen this? I am running VMS V4.3, and can readily reproduce
this in anywhere from 10 minutes to 24 hours...
gkn
---------------------------------------
Arpa: GKN%SDSC.BITNET@WISCVM.WISC.EDU
USPS: Gerard K. Newman
San Diego Supercomputer Center
P.O. Box 85608
San Diego, CA 92138
AT&T: (619) 455-5076