BurnlnTest 6.0.1023 test serial fail

[JeffLee]

My system is
APU-AMD G-series T56N-1.8G
FCH-HUDSON M1
DDR3 1033 2G
SATA HDD 160G


I test Burn test full load 100% these items
1.2D Graphics
2.3D Graphics
3.CPU
4.DISK
5.MEMORY
6.SERIAL PORT 1(SPEED 115200)
7.SERIAL PORT 2(SPEED 115200)
8.SERIAL PORT 3(SPEED 115200)
9.SERIAL PORT 4(SPEED 115200)
10.VIDEO PLAYBACK
~~~~~~~~~~~~~~~~~~~~~
Run almost 1 hour
serial port 1&3 show error "NO OPERATIONS REPORTED IN TIMEOUT PERIOD"
I stop burn in test and run again
serial port 2 show "NO OPERATIONS REPORTED IN TIMEOUT PERIOD"
and serial port 1&3 show error "COM PORT IS ALREADY IN USE BY ANOTHER PROGRAM"
but I no run other program
WHY show these errors

~~~~~~~~~~~~~~~~~~
BTW
I test all serial ports speed 9600
is ok
Why 115200 fail??

[Ian (PassMark)]

It sounds like Serial ports 1 and 3 have been opened for testing in the 1st test run, then have locked up on some action to the COM ports. This stops the BurnInTest COM 1 and COM 3 tests. When you stop the tests, BurnInTest is unable to stop the COM 1 and COM 3 tests - as they are probably hanging in the operating system kernel. So when you run the second test, COM 1 and COM 3 are already open by the previous test.

As the test works at 9600, but not at 115200, then I would suspect a hardware problem. I would first swap the loopback plugs just to make sure the problem is not these (e.g. swap plugs on COM port 1 and 2, and 3 and 4). I would try different combinations of the tests, e.g. just COM 1 at 115200, to try and understand the behavior better. Depending on the additional testing results I would also check you Interrupt settings for the COM ports.

[JeffLee]

I test again burn in test
not every time are com1.3 show error "NO OPERATIONS REPORTED IN TIMEOUT PERIOD"
it is random show error on COM1~COM4
sometime had 3 or 4 com ports show error
and I make sure LOOP BACK are OK
I try speed 9600 to test over night OK
but 115200 fail
is my system busy?? or??

[Ian (PassMark)]

I would not think this is directly related to your system being heavily loaded. I would expect a different error in this case. You should be able to rule out system load by testing the COM ports individually at 115200.

[JeffLee]

I try burn in test again
RUN
1.2D Graphics
2.3D Graphics
3.CPU
4.DISK
5.MEMORY
6.SERIAL PORT 1(SPEED 115200)
7.SERIAL PORT 2(SPEED 115200)
8.SERIAL PORT 3(SPEED 115200)
9.SERIAL PORT 4(SPEED 115200)
10.VIDEO PLAYBACK
every items are 100% loading
almost 12H
COM2.3.4 show error msg"NO OPERATIONS REPORTED IN TIMEOUT PERIOD"

I stop burn in test and just test only serial port 1-4
error show on port 2.3 "Com port detected a Receive Overrun Error"

why error msg are different with first time


I stop again and to adjust COM speed to 57600 test
no more show error msg
speed 9600 is OK no error

why only 115200 speed show error???

ALL devices ,loopbacks and system no changed

just adjust burn in test options

Pls help ~~

[Ian (PassMark)]

COM port detected a Receive Overrun Error:
This warning is related to load on the COM port and the CPUs ability to service the COM port interrupts (ie. CPU load and interrupt priorities). It is reported by a kernel level software driver, rather than hardware. The COM port typically has two 16 byte buffers (on a UART/Super IO chip). One for transmit and one for receive. The "COM port detected a Receive Overrun Error" occurs if data is received by the UART receive buffer when the receive FIFO buffer is full. That is, before a COM port interrupt is serviced by the CPU to copy the receive buffer to RAM. The COM port interrupt trigger level is a Windows setting, this is typically defaulted to 14 - ie. generate a CPU interrupt when 14 of the 16 bytes in the UART buffer are full. In this case the last byte in the UART receive FIFO is overwritten and that data is lost.

This warning can occur when the system is under sufficient load that the CPU can’t service the COM port interrupts in time.

The Serial port test has been designed to use under moderate CPU load. Very high CPU load, especially CPU Interrupt load, may lead to data overrun events as the CPU is unable to handle the Interrupt quickly enough. This is normal under very heavy load.

This would seem consistent with what you are seeing.

You could try the testing with lower CPU interrupt load:
(1) the COM port speed (reduce)
(2) the COM port duty cycle (reduce)
(3) the UART settings (please see: http://support.Microsoft.com/kb/131016/EN-US/ ). For example reduce both buffers to 8 (ensure that the transmit FIFO is not larger than the receive FIFO).

Or reduce the CPU load by reducing the number of tests.