RS/6000 7012-390 RS/370 - S/N 26-79935 (snork)
2 January 2020
Contents
- AIX 3.2.5 installation from QIC
- AIX 3.2.5 installation fails with PVs ≥4GB
- PTF U409194 for X11rte.obj 1.2.3.0 fails to install
- P/370 processor fails RS/370 software diagnostics
Problem Log
AIX 3.2.5 installation from QIC
An ordinary Tandberg QIC-525 drive was borrowed from a Sun and used to IPL from tape 1. No special IBM firmware is required in the tape drive.
AIX 3.2.5 installation fails with PVs ≥4GB
With a maximum of 1016 physical partitions (PPs) per hdisk and the default PP size of 4 MB, the largest disk the installation process is capable of dealing with automatically is 4064 MB. The IBM DCHS 04Y disk is only slightly larger than this; as a result the installation fails when creating rootvg.
To recover, access the maintenance shell and create a rootvg with 8 MB PPs by executing these commands:
# mkvg -f -y rootvg -s 8 -d 1 hdisk0 # varyonvg -n rootvg # exit
Installation will proceed normally from here.
Note: If varyonvg is not successful, the installation process will not proceed, and you will have to re-IPL before trying again. Trying LVM-related commands other than those listed above can prevent varyonvg from being successful. I found the process to be intolerant of experimentation, or even exploration.
PP sizes (the number following -s in mkvg, above) are megabytes, in powers of two. 8 MB was sufficient for the 4.5 GB DCHS 04Y disk. 16 MB or even 32 MB PP sizes may be required for larger disks.
The automated install process is governed by shell scripts in the directory /usr/lpp/bosinst/, which is part of the standalone installation miniroot filesystem. The mechanics of the creation of rootvg are exposed in the shell script /usr/lpp/bosinst/bosrvg
PTF U409194 for X11rte.obj 1.2.3.0 fails to install
This can happen if X11rte.obj is installed simultaneously with its PTFs, owing to a defect in PTF U435140 which will cause it to incorrectly be applied before U409194 (q.v. APAR IX50762). Many other PTFs depend on U409194, but if this happens, U409194 will fail during postprocessing and cause the package to be marked as "broken". Further patching will not be possible until the system is corrected and U409194 re-installed.
Create the following script as /usr/lpp/pcsim/lpp.X11. You may have to create the directory /usr/lpp/pcsim first.
#! /bin/ksh
set -x
if [ `pwd` = /usr/lpp/X11rte/inst_U409194 ] ; then
SMT=""
if [ -f /usr/lpp/X11/bin/smt.exp ] ; then
SMT="-bI:/usr/lpp/X11/bin/smt.exp"
fi
DWA=""
if [ -f /usr/lpp/X11/bin/dwa.exp ] ; then
DWA="-bI:/usr/lpp/X11/bin/dwa.exp"
fi
XDIR="/usr/lpp/X11/bin"
X_LIBS="-lm -ldbm /usr/lpp/gai/libgair4.a -lodm -lc -lcfg"
LD_OPTIONS="-H512 -T512 -bhalt:4 -bE:/usr/lpp/X11/bin/X.exp -bE:/usr/lpp/X11/bin/ddx.exp \
-bE:/usr/lpp/X11/bin/gai.exp -bE:/usr/lpp/X11/bin/Xi.exp $SMT $DWA"
ld $LD_OPTIONS -s -o $XDIR/X /lib/crt0.o $XDIR/X.o $X_LIBS || rm -f $XDIR/X
exit 0
fi
Then execute the following commands to successfully apply the PTF for APAR U409194:
# chmod +x /usr/lpp/pcsim/lpp.X11 # installp -acgNd install_device_or_directory X11rte.obj 1.2.3.0.U409194 # rm /usr/lpp/pcsim/lpp.X11
P/370 processor fails RS/370 software diagnostics
The diagnostic utility provided with p370.obj 03.04.00.00 reports a hardware failure while executing internal test 001C:
# /usr/lpp/p370/bin/diagp370
RS6000/370 DIAGNOSTIC PROGRAM (Version 0.10)
Expanded Message Mode: This may take a few minutes.
TESTING THE PROGRAM ENVIRONMENT:
Re-booting the adapter
TESTING THE BASIC ADAPTER INTERFACE FUNCTIONS:
Testing POS Registers => pos2=0B pos3=90 pos4=02 pos5=E9
Testing Control Registers => ap=00 scp=00 isp=01 cbsp=00
Indy Value => FF
Testing Memory Segment Registers
MSR Value => 0E
Testing Program/Control Register => pcs=8080
Disabling the adapter processor
Testing Control Store RAM Array
WCS Value => 0B
INITIALIZING THE ADAPTER AND RUN ADDITIONAL TESTS:
Opening file: D8FC4.FLS
Loading initialization routine
dtest1.wcs: => Code=0000, Test=0000
Testing the COMBUF => 37E5 0102 0000 0D1A
Testing the Adapter RAM
Testing the Key Array
Testing Adapter Timer => abs=A659 rel=FFFFD901
Testing Interrupts to the adapter => man=71 key=87 i/o=9D
Testing Alerts from the adapter
After dtest1.wcs: => Code=0000, Test=0001
Adapter Initialization successful
TESTING THE ADAPTER WITH INTERNAL TEST ROUTINES:
dtest2.wcs: => Code=0000, Test=0002
Sequencer functional
dtest3.wcs: => Code=0000, Test=0003
Subroutines functional
dtest4.wcs: => Code=0000, Test=0004
Simple test of ALU and shifter complete
dtest5.wcs: => Code=0000, Test=0005
Execution Unit internal registers OK
dtest6.wcs: => Code=0000, Test=0006
Internal flags and counters functional
dtest7.wcs: => Code=0000, Test=0007
Address Unit internal registers OK
dtest8.wcs: => Code=0000, Test=0008
Instruction register tests OK
dtest9.wcs: => Code=0000, Test=0009
General Registers test OK
dtesta.wcs: => Code=0000, Test=000A
Internal alignment hardware tests OK
dtestb.wcs: => Code=0000, Test=000B
Internal byte mask hardware tests OK
dtestc.wcs: => Code=0000, Test=000C
Address Incrementer tests OK
dtestd.wcs: => Code=0000, Test=000D
Address Adder MUX tests OK
dteste.wcs: => Code=0000, Test=000E
Address Adder tests OK
dtestf.wcs: => Code=0000, Test=000F
Internal ALU tests OK
dtest10.wcs: => Code=0000, Test=0010
Shifting by one bit tests OK
dtest11.wcs: => Code=0000, Test=0011
Shifting by multiple bits tests OK
dtest12.wcs: => Code=0000, Test=0012
ALU MUX tests OK
dtest13.wcs: => Code=0000, Test=0013
Condition code logic OK
dtest14.wcs: => Code=0000, Test=0014
Miscellaneous hardware tests OK
dtest15.wcs: => Code=0000, Test=0015
Miscellaneous hardware tests OK
dtest16.wcs: => Code=0000, Test=0016
Internal local store tests OK
dtest17.wcs: => Code=0000, Test=0017
Length register tests OK
dtest18.wcs: => Code=0000, Test=0018
Decimal hardware tests OK
dtest19.wcs: => Code=0000, Test=0019
Translation Lookaside Buffer scan test OK
dtest1a.wcs: => Code=0000, Test=001A
Timers test OK
dtest1b.wcs: => Code=0000, Test=001B
Memory tests OK
dtest1c.wcs: => Code=23F9, Test=001C
Invalid address used by PS/2 in memory access
FAILURE ON CARD, EXCLUDING MEMORY SIMM's:
See last (Error) Message from test routine above.
This error seems to occur regardless of the actual operational status. It is reported with the prototype 370 processor, as well as with both of the GA-level cards I have tested. Each of these appear to run S/370 software normally, despite the reported failure.