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.