18 Aug
2015
18 Aug
'15
5:11 p.m.
On 2015-08-18 17:48, Holm Tiffe wrote:
..that's an experience I still have to make (see below).
In the meantime I found the Emulex CS08 and connected it to the terminal.
The CS08 has a 3 position switch on the breakout panel "N R S" for Normal,
Reset and Setup mode. One can connect a terminal and switch to Setup,
that's what I've done. I've entered the CSR 160440 (17760440) and the
vector 310 like sysgen was showing in sh/config. The Emulex worked,
previous vector was 300 where the problem was the same as on the CXY08.
Now it was pretty clear what the problem was, switched E28/8 to one (Vector
bit 3) on the CXY08, put it in, booted and voila .. its working now.
Understand my quandary: I have changed not a single bit on the hardware
while cleaning and repairing it and besides that DHU11-DHV11 Switch the
board was in the published factory setting!
I've got the machine in exactly this configuration and I'm not a guy that
toggles switches b'cause they are nice looking. That's why I've assumed
that the the hardware is in a working configuration and I've expected
that VMS should complain when a device isn't able to pull an interrupt
while initializing it ..but...
No error in the logs, no error while booting..so what?
Ok. Almost 3 days for such a simple problem..
Oh man... :-(
Ok, the beast seems to be working now as it should. Now I can try to fix
that "not properly dismounted" problem on dia1 ..I've relocated the
pagefile.sys to it b'cause of space considerations ..and VMS is to stupid
to dismount it properly. Next try ist to get the printer(s) working, one
serial and one over TCP/IP Port 9100 (old jet-direct Laserjet). Hopefully
I'm learning again to use the installed c-compiler..
Tomorrow my granddaughter is coming with familiy, time to play is over
then.. :-)
Thanks to all,
Holm
Johnny Billquist wrote:
The thing is. If your CXY08 was configured to use vector 300, you ended
up with an interrupt to the PTB driver, which probably just considered
it a spurious interrupt resulting in no work. If it had actually been a
vector for which no driver was set up, you would probably get an error
log entry about an unexpected interrupt, but the TMSCP controllers are
probably very allowing for interrupts, as they just indicate that the
controller should scan the response ring and pick any new responses.
Johnny
On 2015-08-18 14:17, Holm Tiffe wrote:
That exactly is the question... What makes me wonder is that I've wrote that
the vector of the card schould
be 300...but:
What makes you say the card should have vector 300? $ mcr sysgen
SYSGEN> SH/CONF
System CSR and Vectors on 18-AUG-2015 14:11:12.81
Name: PAA Units: 1 Nexus:0 (CI )
Name: PAB Units: 1 Nexus:1 (CI )
Name: EZA Units: 4 Nexus:2 (NI )
Name: PUA Units: 1 Nexus:3 (UBA) CSR: 772150 Vector1: 154
Vector2: 000
Name: PTA Units: 1 Nexus:3 (UBA) CSR: 774500 Vector1: 260
Vector2: 000
Name: PTB Units: 1 Nexus:3 (UBA) CSR: 760404 Vector1: 300
Vector2: 000
Name: TXA Units: 8 Nexus:3 (UBA) CSR: 760440 Vector1: 310
Vector2: 314
SYSGEN>
...floating vector?
Yes, both PTB and TXA uses a floating vector. PTB also have a higher
"priority" in the configuration scheme, so it comes first. Which means
the vector of TXA becomes 310.
Note that this is the vectors the OS is assuming the device will be
using. It does not mean that the actual hardware is using those vectors.
That is what the switches are for. But they should match what the OS
expect... Or else things will not work well.
Johnny