| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1219.1 | Bridge can't handle a quick response | ROGER::GAUDET | Because the Earth is 2/3 water | Wed Jul 13 1994 13:41 | 8 |
| There should be no difference loading DECbridge 90's or 90FL's. I have had
limited success loading those bridges using DECndu Plus, depending on the type
of system you're loading from. The bridge is not very tolerant when it gets a
quick response to a load request it has made.
FWIW, loading from a VAX using NCP seems to succeed more frequently.
...Roger...
|
| 1219.2 | You have the latest | ROGER::GAUDET | Because the Earth is 2/3 water | Wed Jul 13 1994 13:44 | 8 |
| Oh yeah, V3.1 is the latest code, which is DEWGB_031.SYS.
>> quiver::proj$722:[onehub.release.wgb.v3_1]DEWGB_031.sys and get
>> no files found.
FYI, in the future use NETCAD instead of QUIVER.
...Roger...
|
| 1219.3 | What can I do with them? | ALBANY::BARTLEY | | Wed Jul 13 1994 14:33 | 18 |
| Thanks for the responses. I didn't think there was any difference.
I am loading from a VAX using NCP. After the load fails, I tried
to connect to the bridge and I get what looks like
a firmware/microcode prompt ">>". It gives me a list of commands
EEPROM
FLASH
RESET
TEST
XDATA
and the connection (using NCP conn node) is very unstable. Connections
don't last long enough to try a command.
Any more ideas before I send these to Logistics?
Thanks again,
Dave
|
| 1219.4 | Instability might be caused by NCP | ROGER::GAUDET | Because the Earth is 2/3 water | Thu Jul 14 1994 11:00 | 11 |
| The ">>" prompt means that the flash image is corrupt. In this state the bridge
"should" respond to an NCP TRIGGER command to load the V3.1 code. I am
concerned, though, about your "unstable connection." I doubt that the bridge is
causing this. There may be something else in your network (or the VAX?) that is
responsible for the instability. Can you provide the output from the following
NCP commands:
SHOW NODE xxx CHAR ! xxx = node name you're connecting to
SHOW CIRC yyy CHAR ! yyy = circuit name
...Roger...
|
| 1219.5 | Update Through Backbone Port Only | ALBANY::BARTLEY | | Thu Jul 14 1994 12:52 | 31 |
|
Rodger,
When I opened up this conference this morning,I wound up in note # 51,
which happened to be addressing this same problem (talk about luck).
I had been trying to update the bridges through the workgroup port, I
had the bridge in slot 7 of a DEChub 90 with nothing plugged into the
backbone port. The VAX I was using to update the bridge was within the
workgroup. When I tried to connect to the bridges, the connection was
very shakey.
Bottom line: I took the bridge out and used it standalone with the
workgroup port connect to a Thinwire segment, same thing. I put a
Thinwire xcvr on the backbone and moved the segment and it updated 1st
time, no errors. I had a second bridge to update and had been having
the same problem. I connected up to the backbone port and it too
updated 1st time w/no errors.
TECH TIP: UPDATE THROUGH THE BACKBONE PORT ONLY!!!!!
I went back and looked at BRIDGE_LOAD.TXT, and no mention of this.
Connections to the bridge were still alittle shakey. It had new
firmware running, but would keep scrolling the banner every few
seconds. I terminated to workgroup side and everything became very
stable.
Dave
|
| 1219.6 | Been there | ROGER::GAUDET | Because the Earth is 2/3 water | Thu Jul 14 1994 16:48 | 14 |
| Well I agree with you Dave that the need to terminate the thinwire ports should
be documented in the BRIDGE_LOAD.TXT file. But it *IS* documented in the
DECbridge 90 Owner's Manual. To quote from page 3-2:
NOTE
The ThinWire ports of the DECbridge 90 are not terminated
internally. External 50-ohm terminations are required.
This note is in the "Standalone Installation" section but unforunately is not
duplicated in the "DEChub 90 Backplane Installation" section.
I'm glad you located the problem and was able to get things up and running again.
...Roger...
|
| 1219.7 | Just Nit'n | ALBANY::BARTLEY | | Thu Jul 14 1994 17:30 | 9 |
| The major point here that should be documented in BRIDGE_LOAD.TXT is that
you *can't* upgrade the bridge through the workgroup port. I *was* able to
upgrade through the backbone port without terminating the workgroup side.
Thanks again,
Dave
|
| 1219.8 | Looks like we've had opposite experiences | ROGER::GAUDET | Because the Earth is 2/3 water | Thu Jul 14 1994 17:50 | 9 |
| But that's not true. In fact, I have not had much success at all loading
through the backbone port, but have had very good success loading through the
workgroup side, both in and out of the hub (terminating the backbone port with a
T-connector and two 50-ohm terminators).
The point is that proper termination of both sides of the bridge is essential,
regardless of which side the load/connection comes from.
...Roger...
|
| 1219.9 | | ALBANY::BARTLEY | | Fri Jul 15 1994 16:18 | 3 |
| Go figure. I guess if you try both of them, one is bound to work.
Dave
|
| 1219.10 | Any real solutions | KERNEL::ANSONR | | Thu Nov 03 1994 08:32 | 13 |
|
Hi,
Any more update on this problem when loading decbridge 90fl. We have
a customer having exactly the same symtoms as descibed in previous
notes. When upgrading the bridge image via DECNDU + running on a PC the
bridges go into this 'funny' state with the '>>' prompt. How do you get
out of this state ? What the most reliable method of loading these
bridges ? Any fixes ?
Thanks
Rich
|
| 1219.11 | Use NCP LOAD NODE | BIKINI::KRAUSE | CSC Network Management/Hubs | Tue Nov 29 1994 04:21 | 8 |
| Up to now, the only reliable method of loading DB90 and DB90FL is to use
NCP LOAD NODE on a DECnet system.
I, too, am interested in an update to NDU that correctly handles the
DB90. Maybe HUBwatch V4 will be able to do it? If they just take the NDU
code it won't help...
*Robert
|