Com2 fails when Passmark test CD is used.

[Comark Corp]

This is a strange one - I narrow down the test devices till I'm just testing the two COM ports and the Passmark test CD. COM2 will fail within a minute or so. The error for COM2 is "COM port detected a receive overrun" If I use the Passmark test disk and just do a "data read and verify" the tests pass.

Thanks!

Motherboard is here:
http://www.americanpredator.com/prod...enix_atxg.html
2.8GHz/533FSB processor
i845GE chipset
Passmark 5.0 build 1001
Windows 2000 SP4
512MB of memory

[David (PassMark)]

My guess is that it is a real error.

Accessing the CD has probably prevented the CPU from for servicing the interrupt generated by the COM port and the COM port buffer overflows. Small timing differences probalby make the problem appear then disappear.

Try checking the settings for the COM2 FIFO buffers from the advanced settings in Windows device manager.

-----
David

[Comark Corp]

My guess is that it is a real error.

Accessing the CD has probably prevented the CPU from for servicing the interrupt generated by the COM port and the COM port buffer overflows. Small timing differences probalby make the problem appear then disappear.

Try checking the settings for the COM2 FIFO buffers from the advanced settings in Windows device manager.

-----
David

Hello David,

Thanks for your reply. I have tried playing with the FIFO settings with no change in the failure mode. If I test the exact same setup under Windows XP SP2 - there are no problems. Both of the test setups are fresh installs of the OS - there are no other programs installed besides BurnInTest. I ran the test continuously under Win 2K overnight and used the Passmark test CD "data read and verify" only settings and there were no failures. COM2 only fails when using the "Passmark Test CD" test mode. Do you have any other ideas?

Thanks again.

[Ian (PassMark)]

Interestingly we had another customer report a similar situation about 6 months back. In that case it was clearly a buffer overrun error and changing the 16550 UART FIFO buffer transmit and receive buffers to lower values (so they interrupt the CPU when less data is in the FIFO buffer), and hence the likelihood of overflowing the very small (often 16 byte) buffer is reduced. In this case, the problem also only occurred when run with the CD test and at least 2 COM ports. The customer in this case did a trace on the Front side bus to confirm it was a buffer overrun error as V4.0 of BurnInTest did not report this. This is actually the reason we added the additional serial port error logging (from the UART Line Status Register) to BurnInTest V5.0.

If you set the BurnInTest V5.0 Preference -> logging to turn Level 2 trace logging on and run a test with the 2 COM ports and the CD and send the .trace files to help [at] passmark [dot] com we will have a look and see if it tells us any more.

Best regards,
Ian

[Comark Corp]

OK, this problem has come up again with this motherboard which uses a completely different chipset:
http://www.epox.com.tw/eng/products_content.php?ps=413

Once again, COM2 only fails if I use the passmark test CD. If I use any other type of data disk, the test passes.

[Ian (PassMark)]

The main difference between using the “Data CD read and verify” test vs. “PassMark test CD/DVD” test is that with the PassMark data CD/DVD BurnInTest knows the files, file sizes and data contained. It hence reads the data and verifies it more quickly, hence the data throughput using the PassMark test is greater. This should lead to a greater need for the CPU to service CD interrupts, and hence a greater probability of the COM port receive FIFO buffer overflowing before it is serviced.

COM1 and COM2 will have different interrupt numbers, these determine the priority of the interrupt (see in Device Manager). By default COM1 has a higher interrupt priority than COM2, hence if an interrupt service is going to be late, it will be the one with the lowest priority, ie. COM2. If you switch the COM1 and COM2 interrupt numbers, I would expect COM1 to report the error.

So, I still believe that this is a hardware and Interrupt priority issue. You should reduce the FIFO buffer settings in Windows, and ensure that the Transmit FIFO buffer size is less than or equal to the Receive FIFO buffer size. It should be noted that we have seen UART chips that only support a Receive FIFO setting of 1 and 8, even though Windows allows the options of 1, 4, 8, 14. In the case of the 4 and 14 settings, the behavior is undefined (in our experience this has caused overrun errors).

Best regards,
Ian

[Comark Corp]

snip

So, I still believe that this is a hardware and Interrupt priority issue. You should reduce the FIFO buffer settings in Windows, and ensure that the Transmit FIFO buffer size is less than or equal to the Receive FIFO buffer size. It should be noted that we have seen UART chips that only support a Receive FIFO setting of 1 and 8, even though Windows allows the options of 1, 4, 8, 14. In the case of the 4 and 14 settings, the behavior is undefined (in our experience this has caused overrun errors).

Best regards,
Ian

This kept coming up on different motherboards and was driving me nuts, and I finally found the culprit: For some reason when you do windows 2K baselines on motherboards from some manufacturers, whatever ATAPI controller the optical drive is connected to would default to programmed I/O mode (PIO). Setting the controller device to use DMA mode fixed the problem. Apparently, the increased interrupt loading from the CD drive being in PIO mode would cause interrupts to be lost from the COM ports.

[Ian (PassMark)]

Thanks for updating the post with your findings.

Best regards,
Ian