NAS-139468 / 26.04 / dont reload service that is inactive (#18100)
Again, our CI has been sporadically crashing on the setup routines for
VMs. After my changes to try and remedy this in the most recent PR:
https://github.com/truenas/middleware/pull/18096, the CI immediately
failed again. However, I'm able to see the issue clearly.
The logs show this:
```
[2026/01/26 06:13:27] (WARNING) middlewared.plugins.service_.services.base.call_unit_action_and_wait():309 - ssh.service Reload job finished with result: invalid
[2026/01/26 06:13:27] (WARNING) middlewared.plugins.service_.services.base._verify_service_running():150 - ssh.service Reload completed but service is inactive
[2026/01/26 06:13:27] (ERROR) ServiceService.reload():356 - Service 'ssh' not running after reload
```
Systemd returns "invalid" when attempting to reload an inactive service.
Journal shows the service was inactive at reload time, then started by
something else ~229ms later:
```
Jan 26 06:13:27.461312 truenas systemd[1]: ssh.service: Unit cannot be reloaded because it is inactive.
Jan 26 06:13:27.690777 truenas systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
[5 lines not shown]
NAS-139467 / 26.04 / fix asyncio.Task leak potentiality (#18099)
While diagnosing this issue
https://github.com/truenas/middleware/pull/18096, the following logs
were found 3 seconds after the logs in that PR.
```
[2026/01/26 00:13:50] (ERROR) asyncio.default_exception_handler():1871 - Task was destroyed but it is pending! task: <Task pending name='Task-3273' coro=<RpcWebSocketHandler.process_method_call() done, ...> wait_for=<Future pending cb=[Task.task_wakeup()]>>
[2026/01/26 00:13:50] (ERROR) asyncio.default_exception_handler():1871 - Task was destroyed but it is pending! task: <Task cancelling name='Task-3346' coro=<DBusRouter._receiver() done, ...> wait_for=<Future cancelled>>
```
During our CI runs, this exposed the fact that RPC method calls were
spawned with `asyncio.ensure_future()` (fire-and-forget) and never
tracked. When WebSocket connections closed, pending tasks were not
cancelled or awaited, leaving them orphaned until garbage collection.
Fixes employed:
- Added `pending_tasks: set[asyncio.Task]` to `RpcWebSocketApp`
- Replaced `asyncio.ensure_future()` with `asyncio.create_task()` +
[2 lines not shown]
sysutils/opensbi: update to v1.8.1
In this update, drop the PMP workaround patch for FU540. This will be
fixed in the src tree.
As usual, bump dependent u-boot ports.
Tested by: Klaus Küchemann <maciphone2 at googlemail.com>
Reviewed by: lwhsu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D54421
DAG: Remove softPromoteHalfType
Remove the now unimplemented target hook and associated DAG machinery
for the old half legalization path.
Really fixes #97975
R600: Remove softPromoteHalfType
Also includes a kind of hacky, minimal change to avoid assertions
when softPromoteHalfType is removed to fix kernel arguments
lowered as f16. Half support was never really implemented
for r600, and there just happened to be a few incidental tests
which included a half argument (which were also not even meaningful,
since the function body just folded to nothing due to no callable
function support).
AMDGPU: Move softPromoteHalfType override to R600 only
As expected the code is much worse, but more correct.
We could do a better job with source modifier management around
fp16_to_fp/fp_to_fp16.
riscv: smarter DMAP construction (again)
Extend pmap_bootstrap_dmap() to build the DMAP with 4K-page granularity.
Recently we have been approximating it with 2MB mappings. The motivation
again is the problematic FU540 hardware, which seems to require more
accurate mappings still to avoid triggering its PMP errata.
Although this hardware alone is of little consequence, constructing the
DMAP accurately/correctly may help avoid future surprises.
The implementation contains some repetitive code. This could be
expressed differently, but my guiding principle for these early routines
is that being simple and explicit about what we are doing makes them
easier to comprehend.
See also 762a3224cde6 ("riscv: smarter DMAP construction).
Tested by: Klaus Küchemann <maciphone2 at googlemail.com>
[3 lines not shown]
arm64: Correctly align the SVE signal context
The SVE signal context needs to be correctly aligned. Fix this by
creating a new macro to calculate the needed size to provide this
alignment, and use it when setting and checking the saved SVE signal
context.
Reported by: cperciva
Reviewed by: cperciva, markj
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D54396
(cherry picked from commit a9e77eb7016df70723c208fc09fbd01ec23a732d)
[mlir][tosa] Fix shape inference for broadcast bias in transpose_conv2d and depthwise_conv2d (#177739)
Fix part of #175765
Correct shape inference for `tosa.transpose_conv2d` and
`tosa.depthwise_conv2d` when the bias tensor has `BC == 1` based on the
specification.
Fix getting the bias shape in `transpose_conv2d` (it uses the shape of
the input tensor before).
[CIR] Apply 'side-effect' attribute logic to the function as well. (#177242)
Previous efforts in both the incubator and upstreamed added the 'pure'
and 'const' attribute lowering to calls. This patch completes that
effort by making it also appear on functions with this attribute.
[flang][Lower] Fix UB in location handling (#177944)
Previously `prov` received the address of a variable allocated in stack
memory (the contents of `include`). `prov` would then access that memory
outside of the lifetime of that stack allocation: leading to UB.
This only manifested on thinLTO builds. No added test because
flang/test/Lower/location.f90 covers it (when thinLTO is enabled) and
there are bots guarding the thin-lto configuration.
Fixes #156629
Fixes #176404
[lldb-dap] Join the ProgressEventReporter thread if possible (#176984)
It is not easily noticeable because it mostly happens when ending the
debug session.
