Hi, Marco,
On Tue, Mar 5, 2024 at 4:34 AM Marco Elver <elver@xxxxxxxxxx> wrote:
LoongArch's problem comes from QEMU, I have tested on real machine.
On Mon, 4 Mar 2024 at 19:12, Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
Hi,
I see a number of failures and tracebacks when running the hw_breakpoint
unit tests on various architectures in qemu. Some examples are below.
Is this a potential problem with the unit tests, with the hardware,
or with the qemu emulation of that hardware ?
The test is testing the accounting logic (allocating/deallocating HW
breakpoints), not actually using the breakpoints. That requires that
the architecture reports the correct number of HW breakpoints
available. It looks like it's not doing that.
In other words, is it worthwhile to look into this further, or would
it make more sense to just disable those tests if they fail on a
given hardware/platform ?
It's an arch bug:
https://lore.kernel.org/lkml/Ytl9L0Zn1PVuL1cB@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
Back then we decided to leave the test as-is, given it's reporting an
actual issue. However, since then nothing has changed and the test
continues to exist as a reminder the arch code needs fixing. I suspect
none of us have the time to get to that soon, so we can either leave
things as is, or skip the test on all the broken architectures.
No idea what's going on with loongarch.
[ 7.222500] KTAP version 1
[ 7.226067] 1..1
[ 7.228795] KTAP version 1
[ 7.232737] # Subtest: hw_breakpoint
[ 7.237512] # module: hw_breakpoint_test
[ 7.237520] 1..9
[ 7.442899] ok 1 test_one_cpu
[ 7.443912] ok 2 test_many_cpus
[ 7.451298] ok 3 test_one_task_on_all_cpus
[ 7.456486] ok 4 test_two_tasks_on_all_cpus
[ 7.462291] ok 5 test_one_task_on_one_cpu
[ 7.468293] ok 6 test_one_task_mixed
[ 7.474405] ok 7 test_two_tasks_on_one_cpu
[ 7.479884] ok 8 test_two_tasks_on_one_all_cpus
[ 7.485699] ok 9 test_task_on_all_and_one_cpu
[ 7.491488] # hw_breakpoint: pass:9 fail:0 skip:0 total:9
[ 7.496985] # Totals: pass:9 fail:0 skip:0 total:9
[ 7.503179] ok 1 hw_breakpoint
Huacai