Common LED Problems

105 | 200 | 201 | 221 | 223/229 | 233 | 551,555,557 | 552,554,556 | 553 | 581 | 727 | 869
Steps Required to Obtain a System Dump

105

CPU planar board is not securely seated in the adapter slot on the microchannel bus.


200

Key is in SECURE mode and the system will NOT boot until the key is turned to either NORMAL or SERVICE mode.


201

LV hd5 (boot logical volume) has been corrupted. To correct this situation, perform the following:

  • Boot system in service mode. Either boot the system from boot diskettes or boot tape OF THE SAME VERSION AND LEVEL AS THE SYSTEM.
  • To perform system maintenance functions from the INSTALL and MAINTENANCE menu, enter the following command, where hdisk0 is the drive that contains the boot logical volume (/blv)
    • /usr/sbin/getrootfs hdisk0
  • From maintenance mode make sure /tmp has at least enough free disk space to create the tape image when the ‘bosboot’ command is executed.
  • Make sure /dev/hd6 is swapped on via the lsps -a command.
  • You don’t want to get ‘paging space low’ messages when creating a new boot image on /dev/hd5. Recreate a new boot image by executing the command:
    • bosboot -a -d /dev/hdisk0
  • Turn key to normal mode
  • shutdown -Fr

top of page


221

The NVRAM is potentially corrupted. To correct this situtation, perform the following steps:

  • Boot system in service mode. Either boot the system from boot diskettes or boot tape
  • Select option to perform system maintenance functions from the INSTALL and MAINTENANCE menu.
  • Enter the following command:
    • /usr/sbin/getrootfs hdisk0 from maintenance mode
  • Enter the command
    • bootlist -m normal hdisk0 or whatever your boot drive name is (eg., hdisk1)
  • shutdown -FrIf the above method fails, try the following:
    • Shutdown your machine and unplug your system battery before you power up.
    • Wait 30 minutes for battery to drain.
    • Reconnect battery.
    • Once you power up and a 221 is displayed on your LED
      • flip the key to service mode then back to normal mode
      • plug in system battery

    Once this is done, the NVRAM should return to normal.

top of page


223/229

Cannot boot in normal mode from any of the devices listed in the NVRAM bootlist.

  • Typically the cause of this problem is the machine has just been moved and the SCSI adapter card is not firmly seated in the adapter slot on the microchannel bus. Make sure the card is seated properly and all internal and external SCSI connectors are firmly attached.
  • Another possibility is that a NEW SCSI device has been added to the system and there are two or more devices with the same SCSI ID.

top of page


233

Attempting to IPL from devices specified in NVRAM device list. If diagnostics indicate a bad drive is suspected, BEFORE replacing the physical volume, replace the LOGIC ASSEMBLY on the drive housing first. Saves time in retrying to rebuild a system especially if full backups haven’t been made recently.

top of page


551, 555 or 557

Corrupted file system, JFS log or defective disk


552, 554 or 556

BAD ERROR: Corrupoted file system, JFS log bad IPL record, corrupted boot LV or defecitve disk. The VG rootvg could not be varied on. Most likely scenario is that the VGDA on the default boot drive (hdisk0) got hammered/corrupted. To resolve this problem, try the following:

1) Boot system in service mode. Either boot the system from boot diskettes or boot tape
2) Select option to perform system maintenance functions from the INSTALL and MAINTENANCE menu.
3) Enter the following command:/usr/sbin/getrootfs
hdisk0
from maintenance mode. If there are at least two PVs in the VG rootvg, if one fails to work with this
command, try any of the remaining PVs (eg, /etc/continue hdisk0 or /etc/continue hdisk1)

4) If the importvg command fails, as should the varyonvg command, then perform the following from the command line:

exportvg <VG_NAME>
EXAMPLE: exportvg vg2 removes LV references from ODM but wont write any info to VGDA

importvg -y <VG_NAME> <PV_NAME> EXAMPLE: importvg -y vg2 hdisk1  restores
ODM database from information read from VGDA

varyonvg -m1 <VG_NAME>
EXAMPLE: varyonvg vg2 This command will INSURE that the ODM database MATCHES the characteristics stored in the VGDA (syncs VGDA to ODM)

5) If no error messages are reported by importvg or varyonvg, then goto step ’11’

6) Execute the command: mount

7) If /dev/ram0 is the only mounted filesystem, try the following script entered interactively from the command line: EXAMPLE:
for VG rootvg – if it fails to varyon

for i in hd2 hd3 hd4
do
synclvodm rootvg $i
if [ “$?” -eq 0 ]; then
fsck -fp /dev/$i
fi
done

8) If there are no error messages from the synclvodm command or the fsck command, then mount the following file systems:

mount /dev/hd3 /tmp
mount /dev/hd2 /usr
mount /dev/hd4 /mnt

9) If there are no error messages from these mount commands, then goto step ’11’

10) If the previous step fails or the log redo process fails or indicates any filesystems with an unknown log device, then do the following 2 steps:    

/etc/aix/logform /dev/hd8 ( Answer ‘y’ to the “Destroy /dev/hd8 (y)?” prompt )

LogForm will reformat the log logical volume. The next IPL will take a little longer.

11) Turn key to normal mode

12) Shutdown the system via the command shutdown -Fr. If this doesn’t appear to be working, type
the following at the command line:

    sync; sync;
halt

13) If the problem still persists, consult your local SE before you attempt to RE-INSTALL your system.

top of page


553

Your /etc/inittab file has been corrupted or truncated. To correct this situation, perform the following:

  • boot system in service mode. Either boot the system from boot diskettes or boot tape select option 5 (perform system maintenance) from the INSTALL and MAINTENANCE menu.
  • Enter the command/etc/continue hdisk0 from maintenance mode.
  • Check to see that you have free space on those file systems that are mounted on logical volumes /dev/hd3 and /dev/hd4.
    • If they are full, erase files that aren’t needed.
    • Some space needs to be free on these logical volumes for the system to boot properly.
  • Check to see if the /etc/inittab file looks ok. If not, goto the next step, else consult your local SE for further advice.
  • Place the MOST recent ‘mksysb’ tape into the tape drive. If you don’t have a ‘mksysb’ tape, get your INSTALL/MAINT floppy and insert into your diskette drive.
  • Extract the /etc/inittab file from the media device mentioned.
  • Change directories to root (eg., cd /) first, then execute the following command:
    • restore -xvf/dev/fd0 ./etc/inittab – if a floppy disk
    • restore -xvf/dev/rmt0 ./etc/inittab – if a tape device
  • This will restore the contents of the /etc/inittab file to a reasonable format to boot the system up with.
  • Depending on how current the /etc/inittab file is, you may have to manually add, modify, or delete the contents of this file.
  • shutdown -Fr

top of page


581

TCP/IP problem: This LED is displayed when the /etc/rc.net script is executed.

  • Verify this script is correct or if modifications have been made since the system was last rebooted.
  • Any errors logged during the execution of this script are sent to the /tmp/rc.net.out file.

top of page


727

Printer port is being configured BUT there is NO cable connected to the configured port on the 16-port concentrator OR the RJ-45 cable from the concentrator back to the 64-port card isn’t connected.

  • Either remove the printer in question from the ODM database (eg., rmdev -l lp0 -d) OR
  • Reconnect the printer cable back to the port on the 16-port concentrator OR
  • Re-connect the 16-port concentrator back to the 64-port adapter card. To determine WHICH concentrator box that printer is connected to
  • Count the number of 727s displayed on the LED
  • Subtract two (first two 727s deal with the native serial ports).
  • For example, if the LED count is 17 (minus the two for the native ports), then the second concentrator box is the problem.

top of page


869

Most likely scenario is that you have two or more SCSI devices with the same SCSI id on one SCSI controller. To correct this situation…

  • Change one of the conflicting SCSI devices to use an UNUSED SCSI address (0-7).
  • If this case fails, RESET your SCSI adapter(s).

top of page


Steps Required to Obtain a System Dump

If your CONSOLE device is still operational, perform the following steps:

  • sysdumpdev -l This will determine which device has been assigned as the primary and secondary dump devices
  • sysdumpstart -p (initiate dump to primary device)
  • sysdumpstart -s (initiate dump to secondary device)
  • sysdumpdev -z (indicates if a NEW dump exists)
  • sysdumpdev -L (indicates info about a previous dump)
  • Press keyboard sequence: CTRL-ALT-NUMPAD1 (for primary device)
  • Press keyboard sequence: CTRL-ALT-NUMPAD2 (for secondary device)
    Insert a tape in the tape device you wish to dump the kernel data
    to /usr/sbin/snap -gfkD -o /dev/rmt0

If your system is hung, the user MUST initiate or force a dump of the kernel data via the following:

  • Turn the Key Mode Switch to the SERVICE position
  • Press the RESET button

top of page