I've been testing t2080rdb which come out suprising results.
There are two t2080rdb board are connected each other directly ,assume A and B.
Both of them are started with SDK 2.0 images (dtb,kernel,filesystem).
Next step is, starting the iperf both ways for A and B
At this stage, 8 cores are almost %0 idle and everything seems normal. Traffic is working as expected.
However a random time later (usually around 10 hours), serial console which I connected is locked. I can not do anything over serial console, even traffic is stopped.
Oddly console sends pasts command's data. For example, I start traffic and "top" command and wait until lock, then I can not stop "top" command but I can see the "top" command results refreshing.
When I check CPU, some of them is still %0 idle but some of them is %100 idle, although traffic is stopped. Still can't send any character from console.
RDB can answers the ping requests but does not allow any tcp connection.
Another important note for A and B RDB boards is that, one of them is locked other one is normal.
I could't check any statistics because of console lock.
Have you ever encounter a problem like that? Are there any solution for this?
Idle CPU that is not receiving scheduling-clock interrupts is said to be "dyntick-idle". The CONFIG_NO_HZ_IDLE=y Kconfig option causes the kernel to avoid sending scheduling-clock interrupts to idle CPUs, which is critically important both to battery-powered devices and to highly virtualized mainframes.
Therefore, system with aggressive real-time response constraints often run CONFIG_HZ_PERIODIC=y kernels(or CONFIG_NO_HZ=n) in order to avoid degrading from-idle transition latencies.
This boot parameter "nohz=" that can be used to disable dyntick-idle mode in CONFIG_NO_HZ_IDLE=y kernel by specifying "nohz=off". By the default, the system boot with "nohz=on", enabling dyntick-idle mode.
You should specify "nohz=off" in bootargs to disable dyntick-idle.