| Title: | -={ H A C K E R S }=- |
| Notice: | Write locked - see NOTED::HACKERS |
| Moderator: | DIEHRD::MORRIS |
| Created: | Thu Feb 20 1986 |
| Last Modified: | Mon Aug 03 1992 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 680 |
| Total number of notes: | 5456 |
Hello, all.
I've got a configuration that looks like this:
+----------------+ +-----------------+
| 8700 | | 8600 |
| primary CPU | | backup CPU |
+----------------+ +-----------------+
| |
| DMZ-32 T1 line | DMZ-32 T1 line
+-----------------o o-----------------+
\
\ Data line switch
> 500m |
|
+----------+
| | DMZ-32 remote distribution panel
+----------+
|
v
To factory equipment
My problem is that when I switch over from the primary to the backup CPU,
some of the ports on the DMZ will go out to lunch (e.g. will cease to function
as we know it).
My guess was that this was due the view of the world held by YCDRIVER in
the backup CPU does not match the view of the world held by the UARTs and
buffers in the remote distribution panel. I confirmed this by cycling power
on the remote distribution panel, and all the dead ports came to life again.
Now, I would like to do this reset in software, as the plant I'm in has 4
of these switched DMZs, and they are in widely scattered places.
The method I'm considering is:
o Raise IPL to 31 (powerfail)
o Set UCB$M_POWER in UCB$W_STS for all the ports
o Set the timeout-expected bit and due time to zero
o Lower IPL to 0
What *should* happen is next time the hardware clock interrupts, the software
timer will execute, and all these devices will appear to have timed out.
The YCDRIVER timeout routine should then re-initialize everything, and all
will be right with the world.
Questions:
o Will this work?
o Will it corrupt the I/O database?
Also: I'd really like to see a copy of YCDRIVER.MAR if anybody has one; does
anybody know a location on the net where I can find a copy of the sources?
- HBM
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 573.1 | ^p the thing | MTBLUE::MACKAY_RANDY | Sat Oct 10 1987 11:11 | 14 | |
If the driver has a function of being able to run tell the module
to run self test , that would do it . The i/o user guide looks like
it doesn't . I would guess that you have tried to set the
characteristics of the lines in other ways . Have you tried putting
them in loopback ?
Now if you could just get to the console and poke a ^xaa00 into the
base+2 register , with out crashing .....
B.T.W. no uarts in the whole system , just latches ,ram and 2901 bit
slice micro's .
randy
| |||||