Serial Ports Test (sptest)

This test checks the system's on-board serial ports (zs0, zs1), as well as any Multi-Terminal Interface (ALM2) boards (mcp0, mcp1, mcp2, mcp3). It writes data to the source device and then reads it back from the receiver device, verifying the data after each byte sent.

Intervention Mode must be enabled before clicking the option window button because sptest is not a scalable test.

Syncloop Testing

With this release of SunVTS, sptest has been enhanced to support syncloop testing. Syncloop testing involves sending and receiving data packets as HDLC frames over synchronous serial lines. The syncloop test to sptest runs in three phases.

• The first phase listens to the port for any activity. If no activity is seen for at least four seconds, the test proceeds to the next phase. Otherwise, you are informed that the line is active and the test cannot proceed. sptest exits with an error if the line is active.
• The second phase is called the first packet phase, in which the test attempts to send and receive one packet. If no packets are seen after five attempts, the test exits with an error message. If a packet is returned, the result is compared to the original. If the length and content of the packets do not match exactly, the test issues an error message.

• The third phase is the multiple packet phase, where the test attempts to send many packets through the loop. Because the test has verified the integrity of the link in the first packet phase, the test will not fail after a particular number of time-outs. If a packet is not seen after the wait time expires, a message is displayed. The number and size of the packets sent during this phase is determined by a default value. Each packet is compared with its original for length and content. If a mismatch is detected, the test issues an error message.

Syncloop Testing Software Requirements

Syncloop testing requires that the zsh0 and zsh1 devices are located in /dev. If you don't have these devices configured, make sure the following two lines are in the /etc/devlink.tab file:

type=ddi_pseudo;name=zsh zsh\M0 type=ddi_pseudo;name=clone;minor=zsh zsh

Warning - The white spaces in the lines above must be a single tab character before and after the zsh variables; using spaces will not work.

---

When these lines have been added to the /etc/devlink.tab file:

* Change directories to /kernel/drv, and execute the add_drv zsh command.

If this command does not work at first,

* Execute the rem_drv zsh command and then execute the add_drv zsh command again.

sptest Options

Figure 24-1 sptest

The loopback settings refer to serial port testing. You must use loopback connectors (described in Appendix A, "Loopback Connectors") to connect the CPU board ports you choose. The default is to link ports A and B with a loopback cable, as indicated by a-b. If you choose a only or b only, the SunVTS exerciser tests just that port, and expects a loopback connector on that port. If you choose a b, the program tests ports A and B separately, and expects a loopback connector on each port.

Loopback Assignments In the following table, a represents port a of the CPU board, b represents port b of the CPU board, and the device names of the ports for each CPU board are listed.

Table 24-1

CPU	Port	Async Device	Sync Device
0	a b	zs0 zs1	zsh0 zsh1
1	a b	zs2 zs3	zsh2 * zsh3 *
2	a b	zs4 zs5	zsh4 * zsh5 *
* Currently, only zsh0 and zsh1 ar	e supported by device drivers.

• Test Type selections are a, b, a_b (a and b), a_to_b (a to b). An a to b cable is required if you select a_to_b.
• Test Mode is synchronous testing, asynchronous testing, or both.
• Sync Loopback

  · Internal test -- works with Test Mode a, b, a_b

  · Plug_a_to_a__b_to_b -- a, b, a_b, test types require a loopback plug

  · no_modem_a_to_b -- testing a_to_b and b_to_a requires a sync a to b cable; no modem is required

• Loopback Plug when enabled, provides data transmission loopback testing of the selected serial port. You must attach a loopback connector (See Appendix C) to the serial port being tested. This option is available only in synchronous mode.
• Sync Internal Test when enabled performs a quick internal check of the serial ports on the CPU board. You do not need to connect any loopback connectors to the serial ports to perform this test. This option is available only in synchronous mode.
• Sync a to b Modem Loopback is enabled if the Transmit and Receive clock sources are external (via modem). This option requires that one of the local modems or the remote modems be set in a loopback configuration. This option is available only in synchronous mode.

• Sync Baud Rate sets the baud rate from a menu. The choices are: 110, 300, 600, 1200, 2400, 4800, or 9600 baud. If you have changed the baud rate, the new value is used. This new value may not correspond to what the Baud Rate menu displays.

---

Note - You can only change the baud rate if you are testing in synchronous mode. If you are testing in asynchronous mode, the sptest uses the default baud rate (usually 9600).

---

• Sync Data Type specifies the selected hexadecimal type pattern. The choices are 0x55555555, 0xaaaaaaaa, or random. 0x55555555 and 0xaaaaaaaa are abbreviated on the option menu. This option is only available in synchronous mode.
• Sync Poll Count sets a value to determine how long the test will poll before reporting an error. Increase the value when running a heavy system load; reduce the value when running a light system load.

sptest Test Modes

Sptest supports all these three modes. It uses different test strategy on the serial port according to different mode. Following is the description of sptest under each mode:

Connectivity Mode In this mode, the sptest tries to open the port to determine whether or not the device is connected. If the attempted open failed, a message is returned indicating that the port is not connected. If the port either opens or fails with a busy or exclusive use error, then the port is considered connected and the test mode returns a passed message.

Online Mode In Online mode, sptest tries to minimize the impact on the application being tested. The Online test is separated by sptest into synchronous and asynchronous tests. In synchronous test mode, sptest opens the port and does the same test as the Offline test. In asynchronous test mode, sptest opens the port and checks for exclusive use of the port.

Offline Mode In Offline mode, sptest performs the regular test, such as checking port activity, sending the first packet, and then sending multiple packets.

sptest Command Line Syntax

/opt/SUNWvts/bin/sptest standard_arguments -o dev=device_name,
porta=port_name,T=a,b,a_to_b,a_b, L=test_loopback, M=mode, B=baud_rate,
I=loopback_pattern

Argument	Explanation
dev=device_name	Specifies which serial port(s) to test. There is no default value; you must specify a device name such as: zs0, zs1 zs2, zs3 ..., ...
porta=port_name	Specifies the name of port a of this CPU, i.e. term/a, term/b
M=mode	The default test mode is asynchronous. Specify one of the following modes: asynch synch both
T=test_type	Specifies the type of test, by number: a b a-to-b a-b
L=test_loopback	None Internal Plug Modem

Argument	Explanation (Continued)
B=baud_rate	Specifies one of the following baud rates for synchronous mode: 110 300 600 1200 2400 4800 9600 19200 38400 Note: If you are testing in asynchronous mode, the default baud rate is used (usually 9600).
I=loopback_pattern	The default test data pattern is r. You can specify the following: 5 = 0x55555555 a = 0xaaaaaaaa r = random

sptest Error Messages

6000 Poll device <device_name> error <error_message>

6001 device <device_name> has error

6002 data error on device '<device_name>', exp = <value>,
obs = <value>.

6003 data miscompare, cnt = <number> exp = <value>, obs =
<value>

Probable_Cause(s):

a. Bad serial port b. System software

6004 can't get sync mode info for <device_name>

6005 can't set sync mode info for <device_name>
6006 packet write failed, errno <number>
6007 len <value> should be <value>
6008 Received:
6009 Expected:
6010 <number> packets with wrong data received!
6011 <number> packets left in outbound queueing
6012 <number> packets lost in inbound queueing

Probable_Cause(s):

a. System load too heavy b. Cable connection error

c. Board error

Recommended_Action(s):

a. Rreduce system load. b. Ccheck cable connection

c. If the problem persists, call your authorized Sun service provider.

6013 Device '<device_name>' not responding.  No data
detected after <number> seconds.  Received <number> bytes
out of <number> sent.

Probable_Cause(s):

a. System load too heavy b. Loopback plug missing or defective

c. Bboard error d. Bad serial port

e. System software

Recommended_Action(s):

a. Reduce system load b. Check loopback plug

c. If the problem persists, call your authorized Sun service provider.

8000 cannot open <device_name>, <error_message>
8001 Test Type a_to_b is not allowed on Quick Test!
8002 Couldn't open file '<device_name>': <error_message>
8003 Transmit failed on '<device_name>'.