Linux burnintest 4.1 with kernel 5.12 UART loopback failed

[hpeter]

Hi,

We had tested Linux burnintest 4.1 with ubuntu 20.04 kernel 5.10, it's worked well.
but when we change to Ubuntu mainstream kernel 5.12
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.12/

The serial port test will failed instantly on start. but the serial port is function worked on minicom or zmodem (sz/rz).
It's seems some error on burnintest.

The attachments is logged by "./bit_cmd_line_x64 -d". If need more information, Please notice me.

Thanks

[Tim (PassMark)]

Thanks for the logs, it looks like all the ports stopped working at the same time and after they had all started sending data without any issues.

Given this is a test build of the kernel and there were no issues previous it would be more likely something in the kernel update changed the behaviour, you may need to investigate some of the system logs (eg dmesg) at the same time the errors are occurring, perhaps there is a driver crash at the same time.

Have you tried running less loopbacks (eg 2 or 3) to see if the issue only happens when there are multiple serial devices or high serial loads?

Are you using our serial port loopback plugs, or some from elsewhere?

[GinoChen]

Dear PassMark

I also get the same problem.
We had tests Linux burnintest 4.1 with ubuntu 20.04.2 Kernel 5.8 it's worked well, but when we change to Ubuntu 20.04.3(Kernel 5.11) it didn't work.

[David (PassMark)]

Same comments as above.
It would help if you did some initial investigation and provided some details of your hardware in use.

[GinoChen]

Dear PassMark

I got the Brunintest log in Kernel 5.8 and Kernel 5.11 from same hardware.
I hope the attachment file can be helpful.

Thanks

[GinoChen]

The attached file is Kernel 5.11.

[Simon (PassMark)]

We have been able to reproduce this error using one of our older machines (Kernel 4.16 vs 5.12) and currently looking further into this. Something has obviously changed in the operating system.

[LTA]

Hello,

Same issue using Debian 11 / kernel 5.10.0-9-amd64 ( Debian 5.10.70-1 (2021-09-30) ) / BurnInTest v4.1 (1001).

Using serial loopback plug, no problem using minicom (with & without Hardware Flow Control), no byte received using BIT (with or without Hardware Flow Control).

For information, if I open minicom in parallel of BIT, I can see data's (cf. joined).

BR's

[David (PassMark)]

So we found that the serial port test still works fine if we limit the buffer size for the send request to 64bytes.
If we use a larger buffer (e.g. 128 bytes) the send fails. But the same code worked fine for the last decade on dozens of different Linux distros.

We are suspecting at this point that it is a Linux Kernel regression (i.e. a bug in the new Linux release).
Serial port hardware hasn't really changed for 30 years now, so it is a bit strange that significant changes to Linux's serial port behaviour is added for such standard hardware.

So we could spend days digging into the Linux Kernel code & drivers and maybe figure it.
But we are thinking at this point the quick easy solution is to reduce the buffer size used, as our goal is to have a good hardware test and from a hardware testing point of view the buffer size doesn't matter much.

We also found this similar post. Serial port stopped working after Ubuntu upgrade
https://askubuntu.com/questions/1345...grade-to-20-04

[Tim (PassMark)]

The new build is now available to download.

[GinoChen]

Dear PassMark

We have used Burnintest v4.1 (1002) to test Uart on Kernel 5.10. It can work without problems.
Thank you very much for your help.

[LTA]

Hello,

BurnInTest v4.1 (1002) correct serial test issue with Debian 11 / kernel 5.10.0-9-amd64 ( Debian 5.10.70-1 (2021-09-30) ) too.

Thank you !