On 2020-08-18 15:37, Paul Koning wrote:
On Aug 18, 2020, at 7:39 AM, Johnny Billquist <bqt%update.uu.se@localhost <mailto:bqt%update.uu.se@localhost>> wrote:On 2020-08-18 04:05, Mouse wrote:I was reading a PDF of - or, let me precise, supposedly of - EK-DEQNA-UG-001, the DEQNA "user's guide" (which includes programming doc). It looks like a scan of a paper copy. But I see an inconsistency in it. In receive descriptors, in the first status word, page 58 of the PDF, page 4-9 in internal page numbering, says that bit 12 is DISCARD. When set, indicates that OVF (bit 00), CRCERR (bit 01), and SHORT (bit 03) are valid (that is, they pertain to this packet). This bit is never set unless one of the other three bits is set. Sets bit 14. But the next page says that bits 07:03 are reserved. And bit 2 is called FRAME, so it's not just a typo in the bit number for SHORT. if_qereg.h defines both QE_FRAME and QE_SHORT, but if_qe.c doesn't use either one as far as I can see. Interestingly, there is a comment on QE_SHORT giving a semantic for it, one which as far as I can see is not supported by EK-DEQNA-UG-001, and the file has a DEC copyright and license notice, so I am inclined to suspect that it may know better than the PDF. I don't suppose anyone here knows what the real story is?I don't know the real story, but I can tell that RSX also knows about the short flag, which is bit 3. Seems either DEC forgot to document it, or they tried to remove the documentation of it.Looking at the DELQA, the whole DISCARD bit was removed, as was any reference to the SHORT bit.In the RSX DECnet DEQNA driver, there is a check if the DISCARD is set, and if so, they clear out the SHORT before deciding if there is something to log. If only the SHORT bit was set, the packet is just discarded, if something else is set, it goes to the error log.But that is the only thing related to the SHORT bit I could find. JohnnyLooking at RSTS, I see one reference to the Discard bit but no references to Short. The only reference I see to Discard is in error logging: if Discard is set, the Overrun, Framing, and CRC error bits (bits 0-2) are believed, if Discard is not set those bits are ignored and no error logging is done for the frame. Given what you say about LQA I'm wondering if that is legitimate, but the code is from after my time so I'm not familiar with it.
I should clarify that with regards to the LQA, this is just what I saw in the documentation.
The DECnet/RSX DEQNA driver handles both DEQNA and DELQA. It checks if DISCARD or RUNT is set. If neither, the frame is processed as a good receive.
If RUNT is set, the packet is just discarded.If DISCARD, but no RUNT, then is is checked if any other bits than SHORT is set, and if so, the packet is logged, otherwise just discarded. So at least in theory, DECnet/RSX looks at DISCARD also on a DELQA. But the documentation just says that bit is "reserved", so it might just always be zero, in which case the code will work just fine, and only get to the discard case, if RUNT is set.
Or else the DELQA actually also implements the DISCARD, even though it's not in the documentation, in which case, you have the same error logging potentially happening there.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol