Remote Diagnostics Details

IBM Diagnostics for POS Systems and Peripherals

Remote Operation

Version 4.5.0 October 2009

This release of IBM Diagnostics for POS Systems and Peripherals provides you the capability to run the diagnostics remotely.

The remote diagnostics support is intended to run without having a person in the store to interact with the register. The type of tests run for remote diagnostics is different from the tests run for the USB memory key initiated diagnostics. Remote diagnostics do not run any portion of diagnostic tests that require human interaction such as the part of the POS keyboard diagnostic test where the keys must be pressed. The test coverage is not as extensive for remote diagnostics when compared to the attended USB key initiated diagnostics. As much information is gathered and as many tests as possible are run for remote diagnostics to help in the problem analysis. Please note that none of the utilities found in the memory key based diagnostic package are available through the remote diagnostics

Let’s take a common example:

You are running IBM Director at your enterprise. Through IBM Director, you have access to each register in each store.

The BIOS in your registers are set for Wake On LAN, alternate boot path, and LAN boot as the alternate boot path. A PXE server you have in the store is configured to load the remote diagnostic package you previously downloaded.

If the machine on which you want to run diagnostics remotely is powered off, send a Wake on LAN message (aka Magic Packet) to wake it up and it will begin to boot the diagnostics package from the PXE server. If the machine is not powered off, you will need to provide a mechanism to shut it down prior to requesting that the diagnostics be loaded.

When the diagnostic package is fully loaded and running, all the diagnostic tests for the system unit and attached peripherals will be run. The results will be provided to the PXE server in the form of a results file. When the diagnostics are finished running, the system will shut itself off.

New Additions since Last update:

1: Part C of Section I – Using Non-IBM Director Software

This Document Includes:

I. Remote Diagnostics Setup Requirements

A. Using Remote Deployment Manager(RDM) with IBM Director

B. Using only IBM Director

C. Using Non-IBM Director software

II. Remote Diagnostic Results

Appendix A: Remote Diagnostics Summary File

Appendix B: Remote Diagnostics Unattended Summary File

Appendix C: Sample RDM task

========================================================================================

I. Remote Diagnostics Setup Requirements

This package for diagnostics is intended for those customers who currently have LAN/WAN access to the registers in their stores. The network infrastructure required to run the diagnostics remotely is not provided in the diagnostic package. The diagnostic package is enabled to run within the network infrastructure you provide.

IBM RSS system units have the capability of being PXE booted. The BIOS settings for system units on which you want to run diagnostics remotely must be set to the following settings:

· allow alternate boot path

· alternate boot path is LAN booting

· enable Wake On LAN.

In the store, you will need software packages that provide the following functions:

· TFTP server

· DHCP server

· FTP server

These packages are not provided by the IBM Diagnostics for POS Systems and POS Peripherals.

Use of IBM Director Version 5.2 is suggested in the process of running these diagnostics remotely. If you currently use Remote Deployment Manager (RDM), you can use that package in this process. RDM comes with a TFTP server.

A file specifically for remote diagnostic operation can be downloaded from the IBM RSS hardware support web site - http://www.ibm.com/solutions/retail/store/support

You will need to download the remote diagnostics package from this web site. The package is a ZIP file that must be exploded on your TFTP server. The content of the remote diagnostics package is:

· FTP directory

o Uattended.properties

o Unattended.properties.sample

· TFTP directory

o Pxelinux.cfg directory

§ File named default

o Img2a

o Img3a.rd

o Pxelinux.0

§ Use this file name as the boot file name in the TFTP server setup.

o Version.txt

· Documents

File Description:

Unattended.properties

Defines that the RSS diagnostics are to run in unattended mode and to provide any details for running. For example, definitions for RS-232 attached devices must be added to this file. This file is intended to be changed by the user. By default, UNATTENDED and SYSTEMTEST are set in the file. Definitions for these settings are:

UNATTENDED – This variable is used to enable/disable the unattended operation of the POS peripheral diagnostics. When enabled, the image will boot, execute all the POS peripheral diagnostics routines and then post the results to the ftp site. When disabled, the image will boot and present the diagnostics menu for the user to select the action to be performed. This is similar as booting the image from the memory key. The default for this variable is UNATTENDED=true

SYSTEMTEST – This variable is used to enable/disable the unattended execution of the system board diagnostics (PC-Doctor). When enabled the image will boot, execute the system board diagnostics and then post the results to the ftp server. The default for this variable is SYSTEMTEST=true

Unattended.properties.sample

This is a file containing sample definitions for RS-232 attached devices. This file can be used as a guide for users to add RS-232 attached devices to their unattended.properties file.

Default

This file defines aspects of the environment that the remote diagnostics will run in. This file is intended to be changed by the user to allow the user to identify the FTP server access detail. The items to be changed by the user are:

Server IP address – This is the IP address of the system that will be used to dump all the diagnostics logs using the FTP protocol. This can be changed by modifying the variable called FTPSERVER in the pxelinux configuration file. The default for this is FTPSERVER=192.0.0.1

FTP path – This is the path to the directory where the log files will be placed. This can be specified as “/” for the root of the ftp server or as an absolute path e.g. “/home/user/logs”. This can be changed by modifying the FTPPATH variable in the pxelinux configuration file. The default is FTPPATH=“/”;

FTP User Name – The user has the options of using an anonymous ftp server or one requiring both a user name and a password. This can be changed by modifying the FTPUSER variable in the pxelinux configuration file. It can be set to FTPUSER=Anonymous or as FTPUSER=(any user name) depending on the desired mode. Note that an ftp password will always be required even when the user is Anonymous. In that case the password must be “Anonymous”. The default for this variable is FTPUSER=Anonymous.

FTP User Password – This is the password used to access the ftp server. The default for this variable is FTPPASS=Anonymous.

Img2a

Img3a.rd

Pxelinux.0

These files comprise the PXE image for the remote diagnostics to be loaded into the target machine. Pxelinux.0 is the file identified to be loaded once an IP address has been assigned to the target machine.

A. Using Remote Deployment Manager(RDM) with IBM Director

If you currently use Remote Deployment Manager with IBM Director, perform the following steps:

- Install DHCP Server (Verify DNS Servers option is enabled)

- Install FTP Server (Verify home directory, write access is enabled)

- Install RDM 4.30 (verify TFTP server is installed)

- Create Custom Task on Director Server. A sample RDM task can be found in Appendix C.

- Click OK to save new Custom Task

- Right click on new Custom Task and click Edit

- Click on the Advanced Tab to view the custom task directory

- Copy all the files in the Remote directory to the custom task directory

- After the files are copied, open the pxelinux.cfg directory

- Open the file named “default” and enter your FTP server information and save the file

- Copy the unattended.properties file to the root of your FTP directory

· Be sure to alter the unattended properties file to add any RS-232 devices

Caution: When using RDM to start a remote diagnostics task with the RSS diagnostics package, be aware

that the task on the RDM console may indicate TASK TIMEOUT when the task is actually complete. Monitor the log file named

<machinetype-serialnumber>-summary.log to determine when the remote diagnostics run is complete.

Once you verify the remote diagnostics task is complete, please cancel the RDM task that shows it has timed out.

The machinetype-serialnumber corresponds to the machine type and serial number on the

machine on which the diagnostics have run.

Note: IBM RSS tested running diagnostics remotely using the RDM with IBM Director configuration.

B. Using only IBM Director

If you currently use IBM Director only, perform the following steps:

- Install a DHCP server (Verify DNS Servers option is enabled)

· Name the remote diagnostics pxelinux.0 file to be loaded when IP addr requests come in

- Install FTP Server (Verify home directory, write access is enabled)

- Install an TFTP Server (Verify home directory, write access is enabled in the setup detail for FTP servers)

· The name of the directory where the PXE files are kept is a setup detail required for TFTP servers.

- Configure the TFTP server to PXE boot the remote diagnostic file pxelinux.0

- Note: The location of these servers is dependent on your network configuration.

- Install IBM Director 5.2

- Create a task to perform the remote diagnostic task set.

· The task is to send a Wake On LAN request to the target system

- Copy all the files in the directory identified in the TFTP server setup

- After the files are copied, open the pxelinux.cfg directory

- Open the file named “default” and enter your FTP server information and save the file

- Copy the unattended.properties file to the root of your FTP directory

· Be sure to alter the unattended properties file to add any RS-232 devices you may have. If you have no RS-232 devices, then you don’t need to add anything.

Note: If you PXE boot your registers for normal operation, you will need to change the TFTP server configuration to point to the remote diagnostics file as the file to be served up instead of the normal operational PXE file.

C. Using Non-IBM Director software

If you currently Not using IBM Director, perform the following steps:

- Install a DHCP server (Verify DNS Servers option is enabled)

· Name the remote diagnostics pxelinux.0 file to be loaded when IP addr requests come in

- Install an TFTP Server (Verify home directory, write access is enabled in the setup detail for FTP servers)

· The name of the directory where the PXE files are kept is a setup detail required for TFTP servers.

- Configure the TFTP server to PXE boot the remote diagnostic file pxelinux.0

- Note: The location of these servers is dependent on your network configuration.

- Install FTP Server (Verify home directory, write access is enabled)

- Install a Wake-On-LAN (Magic Packet) capable program.

· If Applicable, Create a task that can send a Wake On LAN request to the target system(s)

- Copy all the files in the directory identified in the TFTP server setup

- After the files are copied, open the pxelinux.cfg directory

- Open the file named “default” and enter your FTP server information and save the file

- Copy the unattended.properties file to the root of your FTP directory

· Be sure to alter the unattended properties file to add any RS-232 devices you may have. If you have no RS-232 devices, then you don’t need to add anything.

========================================================================================

II. Remote Diagnostic Results

The results of a remote diagnostic run are made available in a file on your TFTP server. The location of the file is identified by the FTP PATH you set in your default file. The name of the file is constructed with the machine type and the machine’s serial number. For example, if the machine type is 4851-E14 and the serial number is “1234567”, then the file names associated with the results are IBM4851E14-1234567-summary.log and IBM4851E14-1234567-unattended.log.

A sample summary results file for the mythical 4851E14 machine can be found in Appendix A.

This file shows the results of the system unit device diagnostics.

These are the results of the PC-Doctor diagnostics

A sample unattended results file for the mythical 4851E14 machine can be found in Appendix B.

This file shows the results of the POS peripheral diagnostics.

If you were running the diagnostics using RDM, note that you should monitor the file IBM4851E14-1234567-summary.log to determine when the diagnostics have completed.

========================================================================================

Appendix A: Remote Diagnostics Summary File

*****************************************************************

Summary of Unattended Diagnostics

Machine Type-Model: 4851514

Manufacturer: IBM CORPORATION

Version:

Serial Number: 1234567

UUID: 81ea74053e747720d82b001125a7d609

Bios Version: HHKT110

System RAM: 597 MB

IP Address: Not Set

*****************************************************************

USB Firmware Levels

Device: Product ID: BCD Level:

POSPrinter0 0x4535 263 (0x107)

*****************************************************************

Passed Device Diagnostics: MICR HID

Wed Jan 01 00:46:17 GMT 2003

*****************************************************************

Passed Device Diagnostics: POS Printer HID

Printer Microcode Level: 0x42

Wed Jan 01 00:46:26 GMT 2003

*****************************************************************

Passed System Diagnostics: PC-Doctor System Test

Wed Jan 01 00:46:31 GMT 2003

*****************************************************************

System Diagnostics Device Specific Information

Test Result: Passed

Device: VIA Nehemiah CPU:0

Test Name: Register Test

Test Description: Verifies the CPU registers successfully retain data.

Test Result: Passed

Device: VIA Nehemiah CPU:0

Test Name: Math Register Test

Test Description: Verifies the CPU co-processor, register stack, pointers, and commands are functional.

Test Result: Passed

Device: VIA Nehemiah CPU:0

Test Name: Cache Test

Test Description: Verifies the L2 Cache memory is functional.

Test Result: Passed

Device: VIA Nehemiah CPU:0

Test Name: MMX Test

Test Description: Verifies the CPU supports MMX features.

Test Result: Passed

Device: VIA Nehemiah CPU:0

Test Name: SSE Test

Test Description: Verifies the CPU supports the SSE extensions.

Test Result: Passed

Device: System Memory

Test Name: Advanced Pattern Test

Test Description: Verifies memory cell corruption does not occur from read/write activity on adjacent cells.

Test Result: Passed

Device: System Memory

Test Name: Pattern Test

Test Description: Verifies memory can accurately retain data using a default set of test patterns.

Test Result: Passed

Device: CMOS

Test Name: RTC Rollover Test

Test Description: Verifies the Real-Time Clock accurately performs date and time rollovers.

Test Result: Passed

Device: UHCI Host Controller

Test Name: USB Standard Device Requests Test

Test Description: This test issues standard device requests to a USB device and verifies that the responses follows the USB specification.

Test Result: Passed

Device: IBM USB HUB KEYBOARD

Test Name: USB Standard Device Requests Test

Test Description: This test issues standard device requests to a USB device and verifies that the responses follows the USB specification.

Test Result: Passed

Device: IBM USB HUB KEYBOARD

Test Name: USB Standard Device Requests Test

Test Description: This test issues standard device requests to a USB device and verifies that the responses follows the USB specification.

Test Result: Passed

Device: USB Mouse

Test Name: USB Standard Device Requests Test

Test Description: This test issues standard device requests to a USB device and verifies that the responses follows the USB specification.

Test Result: Passed

Device: UHCI Host Controller

Test Name: USB Standard Device Requests Test

Test Description: This test issues standard device requests to a USB device and verifies that the responses follows the USB specification.

Test Result: Passed

Device: UHCI Host Controller

Test Name: USB Standard Device Requests Test

Test Description: This test issues standard device requests to a USB device and verifies that the responses follows the USB specification.

Test Result: Passed

Device: IBM Retail USB 4610 SureMark Printer

Test Name: USB Standard Device Requests Test

Test Description: This test issues standard device requests to a USB device and verifies that the responses follows the USB specification.

Test Result: Passed

Device: UHCI Host Controller

Test Name: USB Standard Device Requests Test

Test Description: This test issues standard device requests to a USB device and verifies that the responses follows the USB specification.

Test Result: Passed

Device: EHCI Host Controller

Test Name: USB Standard Device Requests Test

Test Description: This test issues standard device requests to a USB device and verifies that the responses follows the USB specification.

Test Result: Passed

Device: USB Flash Memory

Test Name: USB Standard Device Requests Test

Test Description: This test issues standard device requests to a USB device and verifies that the responses follows the USB specification.

Test Result: Passed

Device: USB:5-3

Test Name: USB Standard Device Requests Test

Test Description: This test issues standard device requests to a USB device and verifies that the responses follows the USB specification.

Test Result: Passed

Device: CMOS

Test Name: Pattern Test

Test Description: Verifies the CMOS memory successfully retains data.

Test Result: Passed

Device: WDC WD400BD-23LRA0

Test Name: Random Seek Test

Test Description: Verifies the drive can successfully move the drive heads to random sectors.

Test Result: Passed

Device: WDC WD400BD-23LRA0

Test Name: SMART short self test

Test Description: Initiates a SMART short self-test on drives that support SMART.

Test Result: Passed

Device: COM:A

Test Name: Internal Register Test

Test Description: Verifies the serial port can accurately send and receive data internally.

Test Result: Passed

Device: COM:A

Test Name: Control Signals Test

Test Description: Verifies the serial port control registers can successfully retain data.

Test Result: Passed

Device: COM:A

Test Name: Data Send and Receive Test

Test Description: Verifies the serial port can accurately send and receive data internally at different baud rates.

Test Result: Passed

Device: COM:B

Test Name: Internal Register Test

Test Description: Verifies the serial port can accurately send and receive data internally.

Test Result: Passed

Device: COM:B

Test Name: Control Signals Test

Test Description: Verifies the serial port control registers can successfully retain data.

Test Result: Passed

Device: COM:B

Test Name: Data Send and Receive Test

Test Description: Verifies the serial port can accurately send and receive data internally at different baud rates.

Test Result: Passed

Device: COM:C

Test Name: Internal Register Test

Test Description: Verifies the serial port can accurately send and receive data internally.

Test Result: Passed

Device: COM:C

Test Name: Control Signals Test

Test Description: Verifies the serial port control registers can successfully retain data.

Test Result: Passed

Device: COM:C

Test Name: Data Send and Receive Test

Test Description: Verifies the serial port can accurately send and receive data internally at different baud rates.

Test Result: Passed

Device: COM:E

Test Name: Internal Register Test

Test Description: Verifies the serial port can accurately send and receive data internally.

Test Result: Passed

Device: COM:D

Test Name: Internal Register Test

Test Description: Verifies the serial port can accurately send and receive data internally.

Test Result: Passed

Device: COM:D

Test Name: Control Signals Test

Test Description: Verifies the serial port control registers can successfully retain data.

Test Result: Passed

Device: COM:D

Test Name: Data Send and Receive Test

Test Description: Verifies the serial port can accurately send and receive data internally at different baud rates.

Test Result: Passed

Device: PCIBUS

Test Name: Config Test