[lldb] Improve error and docs for repeating "memory region" (#177559)
"memory region" can be given an address once and then when repeated,
it will try to find a region just beyond the last one it printed.
This continues until the end of the address space.
Then it gives you an error showing the usage, which is odd because
you just saw a bunch of "memory region" with no options work.
So I've improved the error a bit to imply its to do with the repetition.
Then described the repeating behaviour in the help text.
[AMDGPU] Simplify legalization of PHI operands (#177352)
In practice when legalizeOperands is called on a PHI node, the result is
never an SGPR class and the operands are never subregs. Simplify the
code accordingly by using the result regclass for all the inputs. This
includes using an AV class where previously we picked either an AGPR or
VGPR class.
R600: Remove softPromoteHalfType (#177420)
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 (#177419)
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.
native-xtools: use static LLVM libraries
Set the MK_LLVM_LINK_STATIC_LIBRARIES knob to "yes" when building the
native-xtools target. This reverts to the behaviour prior to
2e47f35be5dc.
This avoids a build failure that occurs otherwise, where compilation
fails looking for a libllvmprivate.so that was not built.
It is unclear if this addresses the issue in all instances---some
replies in the PRs indicate otherwise. Still, some report success, and
in my own testing this fixed creation of a cross-compiled poudriere
jail. Commit this while we continue to investigate...
PR: 286710, 291409
Tested by: marck, rdunkle at smallcatbrain.com
Reviewed by: emaste
MFC after: 3 days
Fixes: 2e47f35be5dc ("Convert libllvm, libclang and liblldb into private shared libraries").
[2 lines not shown]
[SDAG] Remove non-canonical fabs libcall handling (#177967)
This is a followup to https://github.com/llvm/llvm-project/pull/171288,
which removed lowering of libcalls to SDAG nodes for most libcalls that
get unconditionally canonicalized to intrinsics. This handles the
remaining fabs case, which I originally skipped due to larger test
impact.
[HLSL] Implement f32tof16() intrinsic (#172469)
Implement the f32tof16() intrinsic, DXIL and SPIRV codegen, and related
tests.
Fixes #99113
---------
Co-authored-by: Tim Corringham <tcorring at amd.com>
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)
