Re: KA630: how does console I/O actually work?

>> I have now switched back to a pure DONE&IE (RX) or RDY&IE (TX)
>> criterion for SLU interrupts.  I find that the ROM selftest is happy
>> but that NetBSD falls into a livelock taking an apparently-endless
>> stream of TX interrupts.

>> I don't yet know more.

I think NetBSD is depending on taking the interrupt being enough to
clear the interrupt.  gencntint() just clears TS_BUSY and calls
gencnstart().  When there is no character available, gencnstart()
checks TS_ASLEEP and, if set, clears it and calls wakeup(), then
unconditionally calls selwakeup(), and...that's it.  Nowhere does it do
anything that would clear either RDY or IE.

For this code to have ever worked, the interrupt must act
edge-triggered in the sense that taking the interrupt causes it to not
recur unless/until its triggering condition arises again.

And, indeed, that's what I see in simh's code.  You wrote of int_req[]
being the analog of an interrupt request signal; consider get_vector()
in vax6530_io.c, which, without clearing any DONE/RDY or IE bits,
clears the relevant bit in int_req[] when computing the vector for an
interrupt.  This behaviour feels very edge-triggered-y to me.

Or, at least, that's what I see as of commit b41d10f189 in what appears
to have been cloned from git://github.com/simh/simh, which of course I
can't git pull from these days.  But git blame says the relevant code
was last changed 2012 (most of get_vector) or 2015 (some of it).  (That
commit is timestamped 2017-03-07.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B