| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 604.1 | Mmmm sounds familiar | CSSAUS::HUNTER | Monkey with a diagnostic track | Tue Nov 24 1987 05:56 | 26 |
|
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.
|
| 604.2 | Addendum... | DPDMAI::BEATTIE | But, Is BLISS ignorance? | Tue Nov 24 1987 11:17 | 24 |
| 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
|
| 604.3 | BI machines have slow response to unibus | OXMYX::POLLAK | Counting trees, in the Sahara. | Tue Nov 24 1987 11:22 | 11 |
|
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.
|
| 604.4 | | OVDVAX::LENNIG | Dave, SWS, @CYO Cincinnati | Wed Nov 25 1987 00:11 | 14 |
| 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
|
| 604.5 | | MARVIN::WARWICK | DNA puts life into your network | Thu Nov 26 1987 12:48 | 3 |
|
SIDRIVER is the driver for the SYNC port on a DMB32 - it is not
at all involved in driving any async. lines.
|
| 604.6 | You're right, Sorry! | DPDMAI::BEATTIE | But, Is BLISS ignorance? | Mon Nov 30 1987 11:00 | 13 |
| 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
|
| 604.7 | | JANUS::PALKA | | Tue Dec 01 1987 05:19 | 17 |
| The TTDRIVER runs a timeout on all transmits. This timeout is stopped
when an XOFF is received and restarted when an XON is received so
normal flow control will not cause it to expire. The timeout value is
calculated depending on the number of characters being sent - I think
it is approximately � second per character. I think the timeout is
calculated and started by the YCDRIVER, and when the timeout expires a
routine in the TTDRIVER is entered and you get the SS$_TIMEOUT error.
The TTDRIVER doesn't put anything in the error log so you wouldn't see
anything there. You could patch the YCDRIVER code which calculates the
timeout value to put a huge number in there (or not to start the timer)
or you could fix the device so that it would pass an XOFF to character
to the VAX when it was unable to send data because the network was
busy.
Andrew
|