| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 121.1 | ?0118 when booting shadow disk | KERNEL::ANTHONY | | Fri Jan 18 1991 23:29 | 164 |
|
FAILURE TO BOOT INTO A SHADOW DISK error ?0118....
o The 6000-500 will give more detailed info during boot than
previous 6000 systems. An example is shown below:
------------------------------------------------------------------------------
(self test matrix)
. . . . . A1 . . . . . . . . ILV
. . . . . 128 . . . . . . . . 128 Mb
Console = V2.00 RBDs = V2.00 EEPROM = 2.00/2.00 SN = GA047H0182
Loading system software
* Initializing adapter
* Specified adapter initialized successfully
* Connecting to storage controller
* Connecting to MSCP server layer
* Connecting to boot disk
* Reading bootblock from disk
* Passing control to transfer address
VAX/VMS Version V5.4-0A Major version id = 1 Minor version id = 0
-------------------------------------------------------------------------------
o The above info is provided by the boot primitive in ROM as it finds
its way out to VMS.
o Error messages are given if the boot fails. These are detailed in the
6000-500 Mini Reference.
o There is an error message that can fool you to believe you have a H/W
problem when booting into a shadow set for the first time. (ie when
the shadow set has not yet been formed).
the error is:
?0118 Specified unit offline-Unit unknown, online to another
controller or port disabled via A,B switches
The problem is due to the Boot Primitive tying to connect to the
VIRTUAL UNIT (specified in R3). It will try to do this 6 times
before giving up, and use the PHYSICAL UNIT (again specified in R3)
THIS IS THE EXPECTED BEHAVIOUR AND IS NOT AN ERROR!
o Before a system can boot through a virtual unit, the shadow set must
be created within the HSC. Once a system has booted VMS through a
physical unit, it will create a shadow set (single/dual volume), and then
systems will be able to BOOT DIRECTLY from the virtual unit.
A complete example of the "failure" is shown below:
-------------------------------------------------------------------------------
>>> SH CONF
Type Rev
1+ KA65A (8080) 000A
9+ MS65A (4001) 0084
D+ CIXCD (0C05) 2453
E+ DEMNA (0c03) 0603
>>> SH BOOT
DEFAULT /XMI:D /NODE:00000100 DU0
STAN /R5:E0000000 /XMI:D /NODE:00000100 DU0
CONV /R5:00000001 /XMI:D /NODE:00000100 DU0
SHAD /R3:80000000 /XMI:D /NODE:00000100 DU0
CD /XMI:E /FILENAME:ISL_LVAX EX0
>>> BOOT/XMI:D/NODE:00000100/R3:80000000 (dus0/dua0)
Initializing system
F E D C B A 9 8 7 6 5 4 3 2 1 0 NODE #
A A . . . M . . . . . . . P TYP
+ + . . . + . . . . . . . + STF
. . . . . . . . . . . . . B BPD
. . . . . . . . . . . . . + ETF
. . . . . . . . . . . . . B BPD
. . . . . A1 . . . . . . . . ILV
. . . . . 128 . . . . . . . . 128 Mb
Console = V2.00 RBDs = V2.00 EEPROM = 2.00/2.00 SN = GA047H0182
Loading system software
* Connecting to shadow unit
* Initializing adapter
* Specified adapter initialized successfully (TRY 1)
* Connecting to storage controller
* Connecting to MSCP server layer
* Connecting to boot disk
?0118 Specified unit offline - Unit unknown, online to
another controller or port disabled via A,B switches
* Previous operation failed - retrying CI boot
* Initializing adapter
* Specified adapter initialized successfully (TRY 2)
* Connecting to storage controller
* Connecting to MSCP server layer
* Connecting to boot disk
?0118 Specified unit offline - Unit unknown, online to
another controller or port disabled via A,B switches
* Previous operation failed - retrying CI boot
* Initializing adapter
* Specified adapter initialized successfully (TRY 3)
* Connecting to storage controller
* Connecting to MSCP server layer
* Connecting to boot disk
?0118 Specified unit offline - Unit unknown, online to
another controller or port disabled via A,B switches
* Previous operation failed - retrying CI boot
* Initializing adapter
* Specified adapter initialized successfully (TRY 4)
* Connecting to storage controller
* Connecting to MSCP server layer
* Connecting to boot disk
?0118 Specified unit offline - Unit unknown, online to
another controller or port disabled via A,B switches
* Previous operation failed - retrying CI boot
* Initializing adapter
* Specified adapter initialized successfully (TRY 5)
* Connecting to storage controller
* Connecting to MSCP server layer
* Connecting to boot disk
?0118 Specified unit offline - Unit unknown, online to
another controller or port disabled via A,B switches
* Previous operation failed - retrying CI boot
* Initializing adapter
* Specified adapter initialized successfully (TRY 6)
* Connecting to storage controller
* Connecting to MSCP server layer
* Connecting to boot disk
?0118 Specified unit offline - Unit unknown, online to
another controller or port disabled via A,B switches
* Failure to connect to shadow unit - retrying on physical unit <-------
* Initializing adapter |
|
* Specified adapter initialized successfully |
* Connecting to storage controller |
* Connecting to MSCP server layer |
* Connecting to boot disk |
* Reading bootblock from disk |
* Passing control to transfer address |
|
VAX/VMS Version V5.4-0A Major version id = 1 Minor version id = 0 |
|
waiting to form or join a VAXcluster system |
%VAXcluster-I-LOADSECDB, loading the cluster security database |
%MSCPLOAD-I-LOADMSCP, loading the MSCP disk server |
. |
. |
. |
Up she comes!. |
|
we have failed to connect to the VIRTUAL UNIT 6 times, now try --|
the PHYSICAL UNIT.
-----------------------------------------------------------------------------
cheers, Brian
|
| 121.2 | Problem with EMUCA copied from YODA after 8/3/91 | KERNEL::BLAND | toward 2000 ... | Thu Mar 21 1991 16:45 | 21 |
| From: YODA::TOURIGNY "But Seriously..... 20-Mar-1991 1416" 20-MAR-1991 19:18:42.81
To: @PROXY_NMAIL.DIS
CC:
Subj: PLEASE TAKE NOTE
Hi,
Note that if you copied DIAG.MLB, DIAG.R32, DIAG.L32 or DIAG.MAR out of
YODA::RELD$0:[ARCHIVE.DS1404.COMMON] or YODA::RELD$0:[43.DS1404.COMMON] after
March 1st, please DO NOT use them! If you need any of them, contact Bob
Bergazzi (YODA::BERGAZZI).
Also, if you copied EMUCA.BIN out of YODA::RELD$0:[43.EVUCA.EVUCA] or
YODA::RELD$0:[ARCHIVE.EVUCA.EVUCA]EMUCA.BIN, after March 8th, please do
not use it. A new version of EMUCA.BIN is now available.
Again, thank you for your time and patience.
Karen
|
| 121.3 | Memory for "VECTOR - PROCESSING" | KERNEL::ADAMS | Venusian turned Aquanaut,-833 3790 | Mon Mar 25 1991 16:47 | 22 |
|
Following a Telesupport call today, the following information
may prove helpful.
The VAX Product Update states the following;
"To utilise the bandwidth of the Vector processor, you must
have interleaved memory (MS65A-xx XMI-2 Memory.)
Ordered configurations will be supplied with multiple smaller
memory configurations, to achieve the total required memory,
e.g Reqd config=128Mb Supplied 2 x MS65A-CA 64Mb arrays."
My engineer had a 6000-510 delivered three weeks ago. The Vector
CPU has just come off engineering hold and will be delivered soon.
It was all ordered as a complete system of 1 scalar cpu/1 vector
cpu/128Mb memory.
Yes, you've guessed it, the memory supplied was 1 x MS65A-DA 128Mb.
Sales are being asked to exchange the MS65-DA for 2 x MS65-CA.
|
| 121.4 | EMUCA.BIN - VECTOR - VAXPAX 43 | KERNEL::BLAND | toward 2000 ... | Tue Mar 26 1991 17:29 | 15 |
|
-< CALYPSO -- VAX 6000-xxx Family Notes >-
================================================================================
Note 837.4 SSB Rel43 6000 Console Patches 4 of 4
PROXY::CROXON "reenignE elosnoC xxx6XAV ESAS" 7 lines 25-MAR-1991 17:47
-< NO VECTORS >-
--------------------------------------------------------------------------------
Jerry,
No! There still is a problem with VECTORs attached. Do not use
EMUCA.BIN in Release 43 with any VECTORs. There is a BLITZ
circulating. The problem will be fixed in the next release (#44).
-Nigel
|
| 121.5 | KLESI & CIXCD or DSSI causes Boot Problem | KERNEL::BLAND | toward 2000 ... | Sat Apr 13 1991 02:42 | 26 |
| This problem/explanation/fix has been extracted from the CALYPSO
notesfile and received a little editing. NORMAN
PROBLEM: 6510 boot problem with KLESI & CIXCD
---------------------------------------------
System configuration has a KLESI & CIXCD.
During the boot the system seems to hang, then prints some errors
from PAA0 and then continues. The tape (TU81) is working under VMS.
The same happens if the TU81 is replaced with a RV20.
If the KLESI is removed,the system boots with no errors.
This problems has been reproduced on 3 different 6510 systems.
EXPLANATION:
------------
The problem is caused when SYSGEN configs the KLESI. As it probes UNIBUS space
a machine check for each non-exsitant memory location which on a MARIAH can
take longer than on past 6000 based machines. This probing and MCHECKING
causes the system to remain above IPL 29 for extended periods. Since the
XCD driver's TQE to write the keepalive timer on the XCD does not get serviced
the timer expires. This timeout causes the port to timeout and reinit its self.
FIX:
----
This problem can be solved by setting the SYSGEN paramter PAPOLLINTERVAL to
20 seconds. This fixes both DSSI and XCD port timeout with the KLESI.
|
| 121.6 | EMUCA.BIN/VAXPAX 50 problem/fix | KERNEL::BLAND | Norman Bland 833 3797 CSC, Basingstoke | Fri Feb 12 1993 01:50 | 89 |
| Here is a new problem (65xx only) and EMUCA.BIN from VAXPAX Release 50.
**************************************************************************
Note 1349.0 New 65XX shadowset boot problem
1 reply
PRSPSU::REY 48 lines
9-FEB-1993 15:28
Hello,
We had the following problem during a maintenance of two 6510's
systems on a cluster at a customer site.
Cluster consisting of:
2-6510's (cixcd)
1-6410 (cibca)
1-HSC50 (V418)
1-HSC40 (V650)
System disks are a shadow set consisting of DUA0 and DUA1, both
RA82's and shadow set is DUS0.
After upgrading the 6510's EEPROM at EE 2.00/3.05 (EVUCA and
EMUCA.BIN of VAXPAX 50) and the 6410 EEPROM at EE 2.03/4.02, we get two
differents scenarios on boot.
Both 6510's are booting from CIXCD. The boot command for one 6510
is:
DEFAULT /R5:10000000/R3:80000000/XMI:D/NODE:0100 DU0
1/ Booting one 6510 first works but the shadow system virtual unit
$1$DUS8192 appears instead of $1$DUS0 as defined on boot command,
and the two others VAXes could't boot normaly.
Same problem when booting the other 6510 first.
I think that the confusion came from the bit 29 of /R3, because
8192 decimal is equal to 2000 Hex ===> /R3:A0000000 ??? why so
confusion...
2/ Booting the 6410 first works fine with the good virtual unit
$1$DUS0, but the boot of the 6510's fails attempting to connect
to shadow unit a lot of times without halting.
We downgraded the 6510's EEPROM at EE 2.00/3.04 and now it OK.
Every boot works correctly.
NB: We had exactly the same problem in other customer site with
a 6510 and a 6410. Same shadow boot problem and same resolution.
Does anyone have any explanation of this new bug, any help is
appreciated.
Best regards,
Jean
**************************************************************************
Note 1349.1 New 65XX shadowset boot problem
1 of 1
PROXY::CROXON "Peanuts, Popcorn, Consoles anyone?" 23 lines
11-FEB-1993 13:40
You have found a bug in the console code. The console is setting this
bit (#29) in the R3 value that it passes to VMS.
This bit indicates to VMS that the console supports Host-Based Volume
Shadowing. The problem is you were not booting a host-based volume.
The following two deposits clear the console from setting bit 29 when
booting. Adding this patch now requires the boot string to contain
bit 29 set when booting host-based volumes on this version.
To fix the console patch, do the following:
>>> E/U/L/P E00A5034
P E00A5034 073C4442
>>> D/U/L/P * 84F901DC
>>> E/U/L/P E00A551C
P E00A551C 0FA02088
>>> D/U/L/P * 01010101
There isn't any other VAX6xxx console at this point that supports HBVS
other than Console = V3.00 EEPROM = V2.00/3.05 on the VAX6500.
These numbers apply to SSB Release #50 EMUCA.BIN, EEPROM V2.00/3.05.
|