| I had exactly the same problem, I followed the instructions and even had the
Agent share the segment of the load host alone.
My load host is also a VMS system, I have the impression that load failure are
due to a resource problem on your load host, request packets or nonpaged pool.
My load host is the bootmember of a small LAVC and the cluster got completely
stuck when I wanted to load the DECagent with the new firmware.(I had no problem
whatsoever with the V1.0 load) Things start getting suspect when I typed the
"start 200000", the cluster activity was slowing down quite a lot and I lost
windows on my station(bootmember).
Finally after many attempts I got the firmware loaded having no clustermembers
and the agent being the only one with which I shared the segment.
I followed the loading instructions as follows:
I first typed NCP> load node xxxxx
immediately thereafter I typed the start 200000 at the agent's console
after a while the load timed out as you described it
then I typed NCP> trigger node xxxxx
and then it worked, I did not dare to retry the load so my statement about the
resources is only a guess...
|
| Since I wrote the code to load the DECagent 90 (you may fire when ready
:-}), I am very interested in knowing why this is not working for you.
NCP on a VMS load host will issue an error similar to the following if
service is DISABLED on the circuit through which you are trying to
load:
%NCP-W-LINCOM, Line communication error
%SYSTEM-F-IVMODE, invalid mode for requested function
Note that enabling circuit service may cause your load host to spend
significantly more time processing certain network traffic (e.g.
broadcast packets). So if circuit service is ENABLED you might be
running into a resource problem (although I'm doubtful that's the
case). My load host is a MicroVAX 3900 loading through a DELQA. Here
are the NCP parameters I have on my VMS system which work for me:
NCP>sho ciruit qna-0 char
Known Circuit Volatile Characteristics as of 6-JUL-1993 12:47:18
Circuit = QNA-0
State = on
Service = enabled
Designated router = 55.1021
Cost = 4
Maximum routers allowed = 33
Router priority = 64
Hello timer = 15
Type = Ethernet
Adjacent node = 55.1021
Listen timer = 45
NCP>sho line qna-0 char
Line Volatile Characteristics as of 6-JUL-1993 12:53:12
Line = QNA-0
Receive buffers = 10
Controller = normal
Protocol = Ethernet
Service timer = 4000
Hardware address = 08-00-2B-0F-8A-36
Device buffer size = 1498
Note that the NCP LOAD command is a "load and wait" process, which
means that once the command is issued you will not be returned to the
NCP prompt until the load is complete. If there is an error, it will
be displayed on the terminal. With NCP TRIGGER, only the initial
boot/load request is issued, then the loading occurs in the background
(sort of a "spawned" LOAD command) and you will be returned to the NCP
prompt. If an error occurs in the load, you will not be notified
unless you have OPCOM logging enabled on your terminal ($ REPLY/ENABLE)
or you check the SYS$MANAGER:OPERATOR.LOG file.
Also, remember that when loading an agent which is in a hub that
contains a bridge, you must be certain that the bridge is not filtering
MOP DL packets (protocol types 60-01 and 60-02) from the backbone. Use
the DECbridge> SHOW PROTOCOL command to see what protocol filters (if
any) are set in the bridge. Obviously, connecting a cable from the
workstation into the right side of the hub (workgroup side) or even
into a thinwire repeater (90C) port that is in the hub will bypass
bridge filtering.
When loading the DECagent using the two-step load procedure, here's
what you should observe regarding the LEDs on the front of the
DECagent:
o After you issue the CCI> START 200000 command, the first three LEDs
should be on and the fourth LED should flash at about a 1/4-second
interval. This indicates that the DECagent is awaiting the boot
request (LOAD or TRIGGER provides this request). Note that there
is no console output generated by the image which is running at this
point.
o Once you issue the LOAD or TRIGGER command at the NCP prompt on the
load host, all the LEDs except the first one should go off. This
should happen very quickly after the NCP command is issued. If it
does not, then either the LOAD/TRIGGER command never made it to the
wire or the DECagent didn't recognize the request. In the latter
case, I am very interested in knowing your configuration and network
load. If things happen as they should, then the first three LEDS
will again be on and the fourth LED will flicker rapidly (now loading
packets into a landing pad area in RAM). After about ten seconds or
so, the flicker should stop (load complete, now calculating the CRC
and writing image to flash RAM). Seven to ten seconds later all the
LEDS will go on (reset in progress) then all but the first LED will
go off. After self-test completes (about 10 seconds), the DECagent
should come up running the new image (first three LEDs on, fourth LED
flickers with network traffic unless there's no IP address set, in
which case the third and fourth LEDs alternately flash at a
one-second interval).
Having other modules in the hub should have no effect on the load
process (with the exception of the bridge filtering issue noted above).
I have had DECserver 90TLs and DECwanrouter 90s attempting to load
their images when a DECagent in the same hub was being loaded and I
have not seen any problems.
Please let me know (with specific details of your configuration) if you
continue to have problems loading DECagents.
Roger Gaudet
DECagent 90 devo.
|
| Hi,
Could someone please supply me with the NCP node characteristics needed
to load the DENMA v1.1 upgrade ?
I have
service circuit = sva-0
hardware address = 08-00-2b-25-07-fc
load file = DENMA011.SYS
software type = system
software identification = denma011.sys
after the denma_load loads and trigger or load results in a device
timeout.
Any ideas ?
Thanks,
Alan.
|
| Assuming you have done CCI>start 200000 (that's two hundred thousand) after
loading DENMA_LOAD.SYS and the LED near the db25 connector is flashing, you
should be able to trigger/load the agent from NCP. If the agent doesn't reset
almost immediately after you issue the trigger/load command (all but the
left-most LED will go off for a second or two), check your connections. All the
DENMA_LOAD.SYS image lives for is to recognize a MOP boot request, which is
issued by NCP trigger/load, then start the load process.
There have been some problems reported by others that are similar to this one
which were discovered to be a bad load image (DENMA011.SYS, not DENMA_LOAD.SYS).
If this is a VMS load host, you might want to verify the integrity of the load
image by doing an $ ANALYZE/IMAGE DENMA011.SYS. If no errors are uncovered, the
image should be OK. You can do this with the DENMA_LOAD.SYS image also. I
don't know how to verify an image (or even if it's possible) on an ULTRIX load
host.
Another thing that comes to mind is that if you have a bridge between the load
host and the DENMA, be sure it is not filtering MOP DL and RC packets (protocol
types 60-01 and 60-02 respectively).
...Roger...
|