tests, task: fix load-dependent test failures

[grandixximo]

Part of #4669. @hdiethelm, this covers the failures you listed. I reproduced them by pinning the test and a few busy loops to one CPU (taskset -c 7).

• touchy, touchy-quit: the sim loaded the gladevcp test panel without -W, so touchy_postgui.hal could run before touchy_test existed and touchy exited. Now loadusr -Wn touchy_test.
• touchy-fit: xwininfo -tree also lists unmapped windows, so window-fit measured touchy before it was mapped. It now polls for a visible window of stable size; an oversized window still fails.
• motion-logger tests: the canon commands queued at startup reached motion only when the UI sent its first command late. On your question about the wait: INTERP_IDLE is already true while interp_list still holds them, so the race stays. The test UIs now wait for s.state == linuxcnc.RCS_DONE, and the expected logs include those commands. startup-gcode-abort waits for EXEC_WAITING_FOR_DELAY instead, since its startup code sits in a dwell.
• hal-show: halcmd's hal_init() right after fork races the loaded module for the next uspace component id. A 200 ms delay there reproduces your 13 => 11 diff. The owner column is masked together with its padding (thanks for catching the 9 vs 10 width).
• gmoccapy: when homing took over 15 s, the retry asked for STATE_ESTOP_RESET with the machine already on, and task never reports that state while traj is enabled. Forcing the first homing wait to 50 ms reproduces your log exactly.
• multiclick, mux: a stream of depth N held only N-1 samples, so the 100 line input never fit before the thread started, and it was preloaded behind a fixed 0.5 s sleep. A late halstreamer left the streamer empty and shifted the end of the output. The tests now use depth 128 and wait for halstreamer with loadusr -w; the stream capacity itself is fixed in hal: a stream of depth N holds N samples #4678.
• halmodule/stream: the reader printed "pass" after ready(), and halrun ends the test at ready, so a late reader was interrupted before printing. It prints first now.
• gmoccapy homing: when homing outlasted the 15 s wait, the retry homed again. X homes past the switch it shares with Z, so the restarted Z began on an active switch and aborted. The test now waits while any joint is still homing.
• gmoccapy sim: X and Z had one shared home switch, so a second home all always failed; each now has its own.
• remap-io: the test polled status after setting the input pin, so under load the "pre" line already showed the new value. It polls first now.
• stop-button-crazy-move: the waits allow 60 s instead of 10 s; each ends as soon as its condition holds.
• linuxcncrsh: this one is in task, not the test. Motion reports a G38.2/G38.4 move that ended without contact one servo cycle after the planner goes idle, but task already counted motion DONE in that cycle. The MDI then finished without the error, and the error was returned for the next command. Task now waits for emcmotStatus.probing to clear before reporting motion DONE, which costs at most one servo cycle. With a program, the same window could let task issue the next line before the probe error. A 50 cycle delay before the verdict reproduces your diff, and it passes with the fix. @BsAtHome, since this is what your linuxcncrsh probe test was hitting, I'd like your view on fixing it in task.

Under load the affected tests went from failing to passing in every run (motion-logger 16/16, touchy tests 3/3 each). The full suite passes apart from blendmath and tool-frame, which don't build with GCC 14 because of EXPORT_SYMBOL (#4673).

[hdiethelm]

Thanks for taking this on! And a good idea to use taskset, so I don't have to reboot my VM between compile and testruns.

Would it be worth creating a scripts/runtests_flaky that basically runs taskset -c 0 scripts/runtests -p -j 32 for a few 100 rounds to check for check flaky tests? Probably not for CI but just to run once in a while and might be before a release.

I was not shure if INTERP_IDLE is the right state... I don't know these parts of linuxcnc well (yet).

I pulled your commits in and will run paralell tests for a few hours. Until now, it looks good! Exept one test that went under in the noise, see: #4669 (comment)

[hdiethelm]

Caught a new one:

--- expected	2026-10-12 19:59:49.609852828 +0200
+++ result	2026-10-12 21:17:22.596376249 +0200
@@ -1,6 +1,6 @@
 Component Pins:
 Owner   Type  Dir                 Value  Name
-    (ignored comp id)  bool  IN                  FALSE  conv-bool-uint.0.in <== net-conv-bool-uint.0.in
+     (ignored comp id)  bool  IN                  FALSE  conv-bool-uint.0.in <== net-conv-bool-uint.0.in
     (ignored comp id)  real  IN                      0  conv-real-sint.0.in <== net-conv-real-sint.0.in
     (ignored comp id)  sint  IN                      0  conv-sint-real.0.in <== net-conv-sint-real.0.in
     (ignored comp id)  sint  IN                      0  conv-sint-uint.0.in <== net-conv-sint-uint.0.in
@@ -36,7 +36,7 @@
 
 Component Pins:
 Owner   Type  Dir                 Value  Name
-    (ignored comp id)  bool  IN                   TRUE  conv-bool-uint.0.in <== net-conv-bool-uint.0.in
+     (ignored comp id)  bool  IN                   TRUE  conv-bool-uint.0.in <== net-conv-bool-uint.0.in
     (ignored comp id)  real  IN           2.147484e+09  conv-real-sint.0.in <== net-conv-real-sint.0.in
     (ignored comp id)  sint  IN            -2147483648  conv-sint-real.0.in <== net-conv-sint-real.0.in
     (ignored comp id)  sint  IN   -9223372036854775808  conv-sint-uint.0.in <== net-conv-sint-uint.0.in
*** /home/hannes/linuxcnc-src/tests/hal-show: FAIL: checkresult exited with 1

Probably an when the ID changes from 10 to 9.
echo " 10 bool IN FALSE conv-bool-uint.0.in <== net-conv-bool-uint.0.in" | sed --regexp-extended --expression='s/^( *)[0-9]+( +[a-z0-9]+ +(IN|OUT|I\/O) .*)$/\1(ignored comp id)\2/'
vs
echo " 9 bool IN FALSE conv-bool-uint.0.in <== net-conv-bool-uint.0.in" | sed --regexp-extended --expression='s/^( *)[0-9]+( +[a-z0-9]+ +(IN|OUT|I\/O) .*)$/\1(ignored comp id)\2/'

sed --regexp-extended --expression='s/^( *)[0-9]+( +[a-z0-9]+ +(IN|OUT|I\/O) .*)$/(ignored comp id)\2/ not adding the spaces before the (ignored comp id) and updating the expected should fix it. I have to admit, chatgpt was of help, regexp are not compatible with my brain.

[grandixximo]

Pushed three more commits: the hal-show padding fix, multiclick/mux, and a task fix for linuxcncrsh (see description).

[BsAtHome]

This is essentially a bug in the streamer/sampler interface in HAL.

When a buffer is requested of size N, then you should be able to put N elements in it. The bug causes only N-1 elements to be available.
The hal_stream* code should be fixed to allocate a buffer of sufficient size to encapsulate the requested size. But the reported max size should also just be N, regardless whether the allocation is one larger. Therefore, this is not the most trivial of fixes.

[grandixximo]

Agreed. I fixed it in hal_lib: a stream of depth N now allocates N+1 slots, holds N samples and still reports N as maxdepth. histobinstream and latencybinstream had a +1 to work around it, which is gone now. The multiclick and mux streamers are back to depth 100, and with loadusr -w halstreamer the test would hang if a 100 deep stream still held only 99. tests/halmodule/stream asserted the old capacity, so it now fills 10 of 10.

[BsAtHome]

Seen the fix. That should do it.

This is such a specific fix that I think it needs to be in its own PR. It isn't a "test-under-load fix", but a bug in HAL stream code.

[grandixximo]

Split out into #4678. This PR is back to streamer depth 128 for multiclick and mux, so it doesn't depend on that fix.

[BsAtHome]

The linuxcncrsh issue, well, it was a probe error that I never was able to find and bothered only when I hit it ;-)

Now that, under load, it has surfaced to be in task, that would be the right place to fix it.