COM port loopback test & settings

[Ian (PassMark)]

BurnInTest runs a test for each serial port simultaneously. With BurnInTest V6.0 you should get a "No operations reported in timeout period" for each serial port that has no operations in at least 8 minutes.

If you are using BurnInTest v6.0, you can email me level 2 trace files files with 1 minute periodic logging for this test I can investigate further. Email address:
http://www.passmark.com/support/index.htm

[elic]

serial port test

after several hours of testing(More than 10 hours),some serial port test will stop(report "no errors","throughput:0Bytes/sec" ).even if pull out loopback,burnintest just the same "no errors",however the other serial port test runing.

[Ian (PassMark)]

I don't know of any issues with this configuration.

Regards,
Ian

[BrooksL]

Ian,

Actually, the failing model I'm testing with is not a dual-core Xeon, but a dual processor board with a single processor installed and Intel Hyper-threading enabled (which makes it act like dual-cores in some ways).

After I disable Hyper-threading in the BIOS Setup, the error rate drops significantly to just a few per 150 cycles.

Again, the error occurs only when testing both COM ports which reside in the Southbridge, at the same time. If one or both ports under test are not in the Intel 6300ESB ICH southbridge, then there is little problem.

So, what are the known and potential issues when testing COM ports with dual processors and/or Intel Hyper-threading enabled?

Please advise.

[BrooksL]

Serial port test error while sending and 1/2 throughput

Ian,

So, the errors do not seem realated to the Intel 6300ESB ICH UART IRQ errata. I found another motherboard with the 6300ESB and ran WinXP SP2, BIT 5.3 serial tests.

I did not get the "error while sending data to COM port" but I still get the 1/2 expected throughput when testing both ports. What have you guys found on this 1/2 throughput issue?

Another difference with the failing motherboard model is that it's a dual-core Xeon processor and chipset. Could that be a problem for BIT using the included WinXP serial port drivers?

Please advise.

[Ian (PassMark)]

It is hard to say, but it sounds possible. It would seem likely that this is a hardware problem.

Regards,
Ian

[BrooksL]

Hi Ian,

I was using the stock Windows serial port drivers in Win2k and WinXP. I tried installing the Intel chipset INF update utility for the E7520 + 6300ESB chipset on the Win2K machine and no change in error behavior (I don't think it has any Intel specific serial port driver in the INF update).

The error almost always occurs on one of the com ports at the beginning of the test, but not always on the same com port. The error does occur again once in a while on each port as the test continues.

No other Passmark tests are running and no other software other than the Windows OS tasks that run after a basic Windows install and boot.

Can you tell me if the 'send data to com port' routine depends upon a receiving a transmitter-empty interrupt? There is an Intel errata about the transmitter empty interrupt on the 6300ESB but Intel considers it minor enough that they didn't see a need to change it. I guess they figure it shouldn't cause a problem for well-behaved drivers.

Thoughts? Could this also be related to the drop in throughput when multiple com ports are tested at the same time?

[Ian (PassMark)]

This error occurs when a write to COM 1 sent less than the expected number of bytes. In this case, on attempting to write 100 bytes to COM port 1, 0 bytes were actually sent. In this case, the detailed error reporting does not really tell you much more than that. The sequence of events seems to indicate that it is the first write the COM port 1 that fails, but after closing and re-opening the COM port the ports seems to work OK.

I am not sure what would cause this specific behavior.
Are you using the built in Microsoft serial port device drivers?
Does the error always at the start of the test?
Does the error always with COM1?
Are you running any other tests at the time, or other software?

Regards,
Ian

[BrooksL]

Error while sending data to COM port (serial loopback)

We are having and issue with running the COM port loopback test and periodically getting the "Error while sending data to COM port" message.

Running WinXP SP2, BIT 5.1, Intel Xeon + 6300ESB ICH Southbridge.

The error only seems to occur while testing both COM ports, usually in the beginning, reccuring ~20~40min when run continuously, regardless of baud rate selection.

Tried, changing ports' I/O address, IRQs, and FIFO settings to 1 byte in Device Manager; no effect on error.

Here's the Activity Level 2 .trace excerpt:

LOG NOTE: 2008-02-15 15:49:46, Serial Port 2, Starting test (fixed baud)
LOG NOTE: 2008-02-15 15:49:46, Serial Port 1, Starting test (fixed baud)
LOG NOTE: 2008-02-15 15:49:47, Serial Port 2, Send 3 blocks of 100 random bytes. (Sample 1 of 100)
LOG NOTE: 2008-02-15 15:49:47, Serial Port 1, Send 3 blocks of 100 random bytes. (Sample 1 of 100)
LOG NOTE: 2008-02-15 15:49:51, Serial Port 2, Read and verify 3 blocks of 100 random bytes. (Sample 1 of 100)
LOG NOTE: 2008-02-15 15:49:51, Serial, \\.\COM1 Error detail: 57.0
LOG NOTE: 2008-02-15 15:49:51, Serial, \\.\COM1 Status detail: 0, 0, 0, 0, 0, 0, 0, 0, 0
LOG NOTE: 2008-02-15 15:49:51, Serial, \\.\COM1 Speed: 19200baud BlockSize: 100 Transferred: 0 Handle:00000558 Total: 0, ErrorCode: 0
CRITICAL : 2008-02-15 15:49:51, Serial, Error while sending data to the COM port
LOG NOTE: 2008-02-15 15:49:52, Serial Port 1, Send 3 blocks of 100 random bytes. (Sample 1 of 100)
LOG NOTE: 2008-02-15 15:49:52, Serial Port 1, Read and verify 3 blocks of 100 random bytes. (Sample 1 of 100)
LOG NOTE: 2008-02-15 15:50:20, Serial Port 2, Send 3 blocks of 100 random bytes. (Sample 1 of 100)
LOG NOTE: 2008-02-15 15:50:20, Serial Port 2, Read and verify 3 blocks of 100 random bytes. (Sample 1 of 100)

This error is not isolated to one motherboard, it's happening on all of them. What can you tell me about what causes this error message?

Please advise,
-- BrooksL

[Ian (PassMark)]

Kevin,

1) Presently there is no way to achieve this. If you would like this functionality, we would be pleased to provide a quotation to add this functionality.

2) To only test certain COM port speeds you will need to use a BurnInTest script. Lets say you want to test COM1 at 9600 for 1 minute and 19200 for 1 minute, you would create two configuration files. For the first, you would set the port speed to 9600 and save this to a configuration file named something like "COM1_9600.bitcfg" (or .cfg if you are using BurnInTest V4.0). For the second, you would set the port speed to 19200 and save the config file as "COM1_19200.bitcfg". In both configurations you should set logging to accumulate results (at the bottom of the logging preferences window).

You would create a script file using any text editor, with something like the following scripting:

####################
#Test COM1 at 9600 and 19200
####################
LOAD "COM1_9600.bitcfg"
SETDURATION 1
LOG "Running Serial COM1 at 9600 for 1 minute"
RUN SERIAL
LOAD "COM1_19200.bitcfg"
SETDURATION 1
LOG "Running Serial COM1 at 19200 for 1 minute"
RUN SERIAL

This is just an example, and there are a number of different ways to script this type of test.

Best regards,
Ian (Passmark)

[Kevin]

Serial Port Speeds

Two questions:

1) I have a serial communications device (RS485) that works at 921.6 kbps and that is the speed I need to be able to test it at. The maximum port speed on the software (BurnInTest Pro v5.0 [registered] for win32) is only 256 kbps. Is there any way that I can change the port speed to match my serial device?

2) I also use the regular RS232 comm ports. Typically I will run these ports at 9600bps, 19200bps, and/or 115.2kbps. Is there any way I can test these three speeds specifically without choosing the 'cycle to 115k' option? Or, even if I could test the upper and lower bounds it would be fine as I'd rather not waste test time by testing at speeds that will never be used.

Thank-you
Kevin

[Ian (PassMark)]

James,

Just further to David's post, it would appear that the source code snippet for this version of Linux enables (for example) the 16550A UART FIFO and sets the Receive FIFO to trigger an interrupt when it has (presumably) 10 bytes (UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10). It does not have a specific Transmit FIFO buffer trigger. It would seem like the UART FIFO buffer interrupt triggers may be hardcoded based on the type of UART chip in the PC. From the perspective of receiving Transmit or Receive buffer overrun errors while testing serial ports with BurnInTest, I suspect this is one the main differences between Windows and Linux.

The BurnInTest COM port test mechanism is the same in both the Windows and Linux versions. The mechanism is basically as follows:

while test running
{
Create buffer of 100 bytes long with random data:
Write 100 byte buffer to COM port x (block 0)
Write 100 byte buffer to COM port x (block 1)
Write 100 byte buffer to COM port x (block 2)
Read 100 bytes from COM port x and verify data (block 0)
Read 100 bytes from COM port x and verify data (block 1)
Read 100 bytes buffer from COM port x and verify data (block 2)
}


The error in your post occurs when on reading the first block of data, 0 bytes are returned (when 100 were expected). The bolded text is the 100 byte random data buffer that was sent (and expected to be available to read). This would normally be the case if the Serial loopback plug was not attached to the COM port under test. Please check the serial loopback plug is attached and try another serial loopback plug to at least rule out the plug.

Also, I would turn on Trace 2 logging and re-do the test. You can post the relevant sections from the .trace file here or send the complete .trace files to help [at] passmark [dot] com.

Best regards,
Ian

[james_tec]

Hi David,

Thanks for your help & info.

I have a couple of questions to ask regarding BUrnintest testing itself:

1. Is there any known difference in the way Linux BurnIntest performs the loopback test for COM port compares to Windows Burnintest? (testing pattern, mechanism etc)

2. We are hoping to get the data pattern generated in Burnintest. I understand that random numbers are used. In what order do the numbers here resemble the instance when an error occurs? Just confirming on how to decode the data pattern here to hardware binary(bolded below).

CRITICAL : 2006-03-29 11:28:11, Serial, Error while receiving from the COM port. Check plug is connected.
LOG NOTE: 2006-03-29 11:28:11, Serial, \\.\COM1 Speed: 115200baud BlockSize: 100 BlockNum: 0 Transferred: 0 Handle:00000548 Total: 0, ErrorCode: 0
LOG NOTE: 2006-03-29 11:28:11, Serial, 29 6B D6 EB 2C A9 3 21 BB EF 5F 5F 4C FC 10 EC BE D4 ED 51 6 45 4D 99 25
LOG NOTE: 2006-03-29 11:28:11, Serial, 8E 51 65 53 5 5C 33 EC 3F 54 16 A7 22 CD CC 8F 60 D4 F3 4E 4A 60 3D CB EE
LOG NOTE: 2006-03-29 11:28:11, Serial, 2F 68 16 75 93 6D 35 33 F4 D 4C E6 5 39 21 10 73 11 8B D0 A1 5A 50 63 91
LOG NOTE: 2006-03-29 11:28:11, Serial, 32 D8 F6 A8 E9 F9 80 72 40 8D 6E 79 EC A1 2B 72 36 92 67 B6 76 35 2A EA DD

Really appreciate your support on this.

Thanks,
James

[David (PassMark)]

Unfortunately we don't know the exact answer.

I did some research in the Kernel source code for you. The serial port FIFO size is set to a different value depending on your hardware and it might also be different in different Linux distributions and in different versions of the Kernel. I was looking at the i386 V2.6.11

You could try posting the question in the Linux user forum for your Linux distribution. If you 'purchased' Linux you might be able to go back to the vendor and ask them the question.

This is what I found the Kernel

static const struct serial8250_config uart_config[] = {
164         [PORT_UNKNOWN] = {
165                 .name           = "unknown",
166                 .fifo_size      = 1,
167                 .tx_loadsz      = 1,
168         },
169         [PORT_8250] = {
170                 .name           = "8250",
171                 .fifo_size      = 1,
172                 .tx_loadsz      = 1,
173         },
174         [PORT_16450] = {
175                 .name           = "16450",
176                 .fifo_size      = 1,
177                 .tx_loadsz      = 1,
178         },
179         [PORT_16550] = {
180                 .name           = "16550",
181                 .fifo_size      = 1,
182                 .tx_loadsz      = 1,
183         },
184         [PORT_16550A] = {
185                 .name           = "16550A",
186                 .fifo_size      = 16,
187                 .tx_loadsz      = 16,
188                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
189                 .flags          = UART_CAP_FIFO,
190         },
191         [PORT_CIRRUS] = {
192                 .name           = "Cirrus",
193                 .fifo_size      = 1,
194                 .tx_loadsz      = 1,
195         },
196         [PORT_16650] = {
197                 .name           = "ST16650",
198                 .fifo_size      = 1,
199                 .tx_loadsz      = 1,
200                 .flags          = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP,
201         },
202         [PORT_16650V2] = {
203                 .name           = "ST16650V2",
204                 .fifo_size      = 32,
205                 .tx_loadsz      = 16,
206                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_01 |
207                                   UART_FCR_T_TRIG_00,
208                 .flags          = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP,
209         },
210         [PORT_16750] = {
211                 .name           = "TI16750",
212                 .fifo_size      = 64,
213                 .tx_loadsz      = 64,
214                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10 |
215                                   UART_FCR7_64BYTE,
216                 .flags          = UART_CAP_FIFO | UART_CAP_SLEEP | UART_CAP_AFE,
217         },
218         [PORT_STARTECH] = {
219                 .name           = "Startech",
220                 .fifo_size      = 1,
221                 .tx_loadsz      = 1,
222         },
223         [PORT_16C950] = {
224                 .name           = "16C950/954",
225                 .fifo_size      = 128,
226                 .tx_loadsz      = 128,
227                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
228                 .flags          = UART_CAP_FIFO,
229         },
230         [PORT_16654] = {
231                 .name           = "ST16654",
232                 .fifo_size      = 64,
233                 .tx_loadsz      = 32,
234                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_01 |
235                                   UART_FCR_T_TRIG_10,
236                 .flags          = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP,
237         },
238         [PORT_16850] = {
239                 .name           = "XR16850",
240                 .fifo_size      = 128,
241                 .tx_loadsz      = 128,
242                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
243                 .flags          = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP,
244         },
245         [PORT_RSA] = {
246                 .name           = "RSA",
247                 .fifo_size      = 2048,
248                 .tx_loadsz      = 2048,
249                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_11,
250                 .flags          = UART_CAP_FIFO,
251         },
252         [PORT_NS16550A] = {
253                 .name           = "NS16550A",
254                 .fifo_size      = 16,
255                 .tx_loadsz      = 16,
256                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
257                 .flags          = UART_CAP_FIFO | UART_NATSEMI,
258         },
259         [PORT_XSCALE] = {
260                 .name           = "XScale",
261                 .fifo_size      = 32,
262                 .tx_loadsz      = 32,
263                 .fcr            = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
264                 .flags          = UART_CAP_FIFO,
265         },
266 };

------
David

[james_tec]

Hi David,

Thanks.
I've read that in the linux website before & I understand that we cannot set the UART FIFO buffer directly but is there any way we can retrieve the buffer default settings on that?
Cheers.

Regards,
James