Conference noted::hackers_v1

    
    Your problem sounds a *little* like one that I have seen here with
    two products. The scenario is as follows.
    
    1. Host initiates an operation and starts timer.
    
    2. Device completes operation and firmware posts a host interrupt.
    
    3. Then device firmware sets up status register(s).
    
    2.5 In the meantime the host has serviced the interrupt and seen no
    valid status info and so dismisses the interrupt as invalid.
    
    4. The host timer expires and posts a device timeout error to the
    error logger etc.

    Obviously what the firmware should have done was to set up the status
    register and then post the interrupt. The 8550 being such a quick
    machine may be outrunning the poor old terminal device.
    
    If you are using the terminal class driver TTDRIVER then you may
    like to try modifying the SYSGEN parameter TTY_TIMEOUT. (I think
    that is its name).
    
                                                           
    Warwick.

    Thanks for your diagnosis.  That also sounds like a possibility.
    
    I'm somewhat befuddled by the fact, however, that nothing is posting
    any device error corresponding to the timeout.  Surely if the registers
    were garbage when the host responds to the posted interrupt, we
    would be reporting something, no?  There is evidence at least some
    error reporting is done from the third party gear (but only
    circumstancial, since I don't have driver sources or hardware spec's
    [*sigh*]).
    
    I've looked at TTY_* SYSGEN parameters, without finding one that
    seems to address the issue.  TTY_TIMEOUT is the logout timer for
    disconnected processes.  TTY_SILOTIME controls interrupt rates for
    DMF-32 input.  TTY_SCANDELTA sets the inspection interval for EIA
    signal change interrupts.  Nothing else documented seems to come
    close [*SIGH!*]
    
    I need to add that the DEC YCDRIVER is also involved.  As I understand
    it, the SIDRIVER (foreign) talks to the device; the YCDRIVER to
    the SIDRIVER, and the CLASS driver to the YCDRIVER...
    
    Thanks again for any help.
    					- Brian
    

    
     If memory serves me correctly in the driver class that I took they
    said that the BI based machines had problems with some devices timing
    out due to the fact that the unibus adapter has to go through a
    couple of other adaptors before it gets on the BI. As a consequence
    it is possible under varying load conditions for a unibus device
    to time out. The only solution was to make the time out longer or
    find a BI equivalent device.

    
    

    re:.3
    I believe the timeout you are referencing has to do with certain
    bus transactions, which is at the hardware level. There are no software
    timers which will address this.
    re:.0
    *IF* this is the nature of your problem, insure the UBA is in the
    first BI slot, reduce the contention on the Unibus, and hope.
    
    I'm a little blurry in this area, (and I don't see how "YC" could
    be layered on "SI" driver) but if I recall correctly that YCDRIVER
    is the DMZ32 port driver, there was a problem in it at one time
    which yielded device timeouts on output.
    
    Dave

    
    SIDRIVER is the driver for the SYNC port on a DMB32 - it is not
    at all involved in driving any async. lines.

    RE: .4, .5, and especially .2 (*sigh*)
    
    My mistake gentlemen.  I misinterpretted and assumed (bad under
    any circumstance); my sincerest appologies!  The HARDWARE emulates 
    the 64 DMF-32 asynch ports that appear in the configuration.  Quite
    correct is .4, that the YCDRIVER is talking directly to the hardware,
    and .5 that the SI driver is DECware, and not involved.
    
    I guess the question then becomes: Doesn't the YC driver time the
    I/O (assert an entry on the timer queue) and signal the timeouts
    as device errors?  And can (or should) the interval be adjusted?
    
                            		-- Brian