NAS-140652 / 25.10.6 / fix nvme self-test error alert (buggy firmware) (by yocalebo) (by bugclerk) (#19442)
## Summary
Fix `parse_nvme_smart_info` in the SMART alert source to select the
newest
NVMe self-test log entry and to tolerate sparse gaps in the table,
eliminating transient false `"failed a SMART selftest"` alerts that
appear
and self-clear every 90 minutes (the alert's poll cadence).
## Root Cause
`parse_nvme_smart_info` used `table[-1]` while naming the variable
`latest_entry`, but `[-1]` is the *last* (oldest) element, not the
newest.
Per the NVMe specification, the Device Self-Test Log (Log 0x06) stores
result entries in reverse chronological order — **index `0` is the most
recent test.** Using `[-1]` meant the alert was actually evaluating the
[94 lines not shown]
Export ServiceOptions from the v26_0_0 API module
## Problem
`plugins/smb_/sid.py` imports `ServiceOptions` from `middlewared.api.current`, but `api/v26_0_0/service.py` defines the class without listing it in `__all__`. Since `v26_0_0/__init__.py` pulls the module in with `from .service import *`, the name never gets rebound and the import raises `ImportError` at plugin load. `load_modules` doesn't guard `importlib.import_module`, so this is fatal — middlewared won't start. It only shows up on 26 because master's `api/current.py` points at `v27_0_0`, whose `__all__` does export the name.
## Solution
Added `ServiceOptions` to `v26_0_0/service.py`'s `__all__`, matching v27. An AST sweep of every name imported from `middlewared.api.current` across the tree confirms this was the only one missing from v26's exports, so nothing else is queued behind it. `ServiceUpdate` is also unexported relative to v27, but nothing imports it through `api.current`, so I left it alone.
(cherry picked from commit 5357bc0b4642706aeb547ced9deea93d4553a835)
[lldb][Windows] Check for EOF before the ctrl-c retry in GetLine (#212745)
On Windows `lldb --repl` can hang forever instead of exiting at EOF.
`IOHandlerEditline::GetLine` checks `GetLastError() ==
ERROR_OPERATION_ABORTED` and does a `continue` before checking `feof`.
However `fgets` is a CRT function and does not set the Win32 last error
value, so the `GetLastError` read is not the expected error. When it
happens to be `ERROR_OPERATION_ABORTED` (995) the loop never reaches the
EOF check.
This reorders the checks so EOF wins unconditionally, and adds
`clearerr` before the ctrl-c retry (a real interrupt leaves the error
flag set, which would fail the next `fgets`). ctrl-c handling is
otherwise unchanged.
rdar://183335061
cad/openvsp: Update to 3.51.2
ChangeLog:
https://openvsp.org/blogs/announcements/2026/07/26/openvsp-3-51-2-released
Features:
* More AI assisted profile guided optimization, mostly in CFDMesh
* Bogie interaction routines added to API
* MakeMeshGeom added to API
Build System:
* Update Code-Eli with some speedups
Fixes:
* Fix locking for APIShow/HideScreenHandler
* Fix AR of API driven screenshots
[3 lines not shown]
[JumpThreading] Materialize PHIs in duplicateCondBranchOnPHIIntoPred (#204859)
In duplicateCondBranchOnPHIIntoPred, updateSSA iteratively updates the
uses of
the instructions of BB (the duplicated block) according to ValueMapping.
For
PHIs, however, the mapping is inconsistent: the keys refer to the values
before
the parallel assignment of the PHIs, while the mapped-to values refer to
the
values after it. E.g.
BB:
%arr = phi [ %ov.0, %PredBB ], ...
%ov.0 = phi [ %ov.sel, %PredBB ], ...
--->
%arr => %ov.0
%ov.0 => %ov.sel
[24 lines not shown]
GlobalISel: Fix lowerMergeValues when dst type is float
Lowering is done in the integer domain. Similar to the type
mismatch when dst is a pointer, make a bitcast when dst is float.
[libc++][pstl] Implementation of a parallel std::adjacent_find() based on std::mismatch() (#210604)
This PR implements a parallel `std::adjacent_find()` based on parallel
`std::mismatch`. The implementation reshapes the input range as two ranges
offset by 1 element and asks `std::mismatch` to find the first equal pair.
Part of #99938.
AMDGPU: Remove xnack and sramecc subtarget features
Now that these are controlled by module flags, the subtarget
features were just used for assembler and disassembler controls.
Now that the assembler and disassembler can infer these from
the e_flags and target directives, they are no longer necessary.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
AMDGPU: Only disassemble .amdhsa_reserve_xnack_mask on xnack targets
The disassembler unconditionally printed .amdhsa_reserve_xnack_mask when
emitting a kernel descriptor. Targets that do not support xnack have no
xnack mask to reserve, and the assembler streamer already only emits the
directive when the subtarget supports xnack. Match that behavior in the
disassembler so the round-trip is consistent and gfx11/gfx12 descriptors
no longer carry a spurious directive.
As a guard against a malformed binary, if the object's ELF e_flags
erroneously select xnack "on" for a target that does not support xnack,
still print the directive so the invalid state remains visible in the
disassembly rather than being silently dropped.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
Migrate legacy containers on HA systems
## Problem
The `system.ready` handler that triggers the incus->container migration returns early on failover-licensed systems, since the failover event plugin owns starting containers there. That path only starts them, it never migrates, so legacy incus containers on an HA pair are never brought across - and `.ix-virt` is no longer hidden or delete-guarded, so they are one dataset deletion away from being destroyed.
## Solution
Move the migrate-then-start ordering into a shared private method and call it from both the `system.ready` path and the failover path, so the two cannot drift apart again.
Leave the legacy datasets as the migration found them
## Problem
Two loose ends in the migration's clean-up. Migrating a pool gives `<pool>/.ix-virt` and `<pool>/.ix-virt/containers` an inherited mountpoint so their children can be mounted and never puts it back, permanently promoting the legacy tree into `/mnt/<pool>/.ix-virt` even on a run where nothing was migrated - incus had both at `mountpoint=legacy`, i.e. never mounted. And when a skipped container's own mount properties cannot be restored, that is reported only in the middleware log, while every other per-container outcome goes to the job log the user actually reads.
## Solution
Restore `mountpoint=legacy` on both parents once a pool has been processed, children first so the parent is not unmounted out from under one of them; a failure there is logged and does not fail the migration. Pass the job into the per-container revert so its two failure paths are reported in the job log as well.
Move a container back when its database row cannot be created
## Problem
The migration renames a container's dataset into `.truenas_containers` and only then creates its database row. If anything in between fails, the dataset is left where nothing can reach it: the migration only ever scans `.ix-virt`, and the native tree is hidden from dataset queries and refuses deletion - so the container is invisible in the UI, cannot be removed, and its name cannot be reused.
## Solution
Track whether the rename happened and whether the row was created. On failure move the dataset back into `.ix-virt` and re-arm the mount-property revert, so a container that could not be migrated is left exactly as it was found. A failure after the row exists is left alone, since the container is real at that point.
Relocate migrated container origins out of legacy .ix-virt
## Problem
Incus containers are ZFS clones of an image snapshot. The incus->container auto-migration relocated each container from `<pool>/.ix-virt/containers/<name>` to `<pool>/.truenas_containers/containers/<name>` with a bare `zfs rename` and did nothing else. A `zfs rename` does not change a clone's `origin`, so a migrated container stayed a clone of a snapshot still living inside `.ix-virt`. `.ix-virt` was visible in the UI and not delete-guarded, so deleting it recursively destroyed those origin snapshots and cascaded into the dependent migrated clones — silently destroying migrated containers.
## Solution
Relocate each container's origin image dataset out of `.ix-virt` before renaming the container, so no migrated container depends on anything under `.ix-virt`. Once relocated the image stays put for good, exactly like a natively pulled one — reclaiming either is the job of the `container.image.*` management API landing separately in this release, not of this fix.
- **Shared relocation helper** — `container.relocate_container_origin` reads a container's live `origin`; if it points at an image under `.ix-virt/images` or `.ix-virt/deleted/images`, it sets `canmount=noauto` on that image dataset and then renames it into the native `.truenas_containers/images/` tree. The rename goes last so it is the single atomic commit point: the image is either wholly still in `.ix-virt` or wholly relocated, never half-way, and the helper's return value describes reality. All fan-out clones auto-repoint on the rename; an origin already outside `.ix-virt` is left alone; a relocation failure leaves the container wholly inside `.ix-virt` (best-effort, skip).
- **Migration path** — the incus->container migration calls the helper immediately before renaming each container, and skips any container whose base image cannot be relocated.
- **Repair migration** — new `0020_repair_incus_clone_origins` runs the same relocation over existing `container.container` rows for systems that already ran the old migration.
- **Delete guard** — `.truenas_containers` is added to `INTERNAL_PATHS` so it cannot be deleted out from under running containers; the plugin's own snapshot/clone/destroy calls that touch it now pass `bypass=True`.
- **Safer deletion** — `do_delete` destroys the dataset first (recursively, matching the apps stack, so a container that has snapshots is deletable) and removes the database and libvirt records only once the dataset is confirmed gone, so a failed destroy never orphans the dataset with no row pointing at it; an already-missing dataset is tolerated so a container whose data was lost to the old cascade can still be removed cleanly.
- **Active-instance guards** — deleting or renaming a container that is not stopped (running or suspended) is refused; delete additionally accepts `force=True`, which stops it first, mirroring the VM delete flow. The container status model now includes the `SUSPENDED` state it can actually report.
- **Delete locking** — delete becomes a job so it can stop the container and wait on the destroy, and its lock is keyed per container id: a constant lock string would hit `@job`'s default `lock_queue_size` of 5 and, past five queued deletes, silently fold a new request into a queued delete of a *different* container and hand that job back to the caller, who would then see SUCCESS for a container nobody deleted.
Arm the mount-property revert before the properties are changed
## Problem
The migration mounts each legacy container to read its manifest, which means replacing the `canmount`/`mountpoint` pair incus set, and a `finally` restores them for any container that is not migrated. The flag guarding that restore was only set once the mount had succeeded, so a failure part-way through the property update - `canmount` applied, `mountpoint` not - left the dataset changed with nothing left to change it back.
## Solution
Set the flag before the properties are touched rather than after the mount.
Always restore the legacy parent mountpoints
## Problem
Two paths leave `<pool>/.ix-virt` with an inherited mountpoint, which keeps the whole legacy tree mounted under `/mnt` and remounted on every boot with nothing managing it. `processed_parents_mountpoints` is only set once both parent updates have succeeded, so a failure on the second one skips the restore at the end of the run entirely. Separately, a system that migrated on an older build never got the restore in the first place.
## Solution
Arm the flag before the properties are changed, the same way the per-container revert already is, so a partial apply is undone too. Have the repair migration call `container.restore_legacy_parent_mountpoints` for every pool it still finds a legacy tree on: the children inherit their mountpoint from `.ix-virt`, so putting the parents back unmounts the tree and keeps it unmounted across a pool import. Pools that are not imported, and trees that are already gone, are skipped rather than logging a failure per dataset.
Record containers created during the migration
## Problem
The set of existing container names is built once before the storage pools are walked, so a container the migration itself creates is never added to it. Two legacy containers with the same name in different pools therefore both proceed, and the second one fails validation after its dataset has already been renamed.
## Solution
Add each container to the set as it is created, so a later pool skips the name instead of failing on it.
Keep migrating the remaining pools when one fails
## Problem
`container.migrate` walks the legacy storage pools with no error handling around each one, so a pool that cannot be prepared - locked, exported, out of space - aborts the whole job and every pool after it is left unmigrated. Which pools those are is arbitrary, since the pool set has no meaningful iteration order.
## Solution
Wrap each per-pool call, record the failure in both the job log and the middleware log, and carry on with the next pool.
AMDGPU: Only disassemble .amdhsa_reserve_xnack_mask on xnack targets
The disassembler unconditionally printed .amdhsa_reserve_xnack_mask when
emitting a kernel descriptor. Targets that do not support xnack have no
xnack mask to reserve, and the assembler streamer already only emits the
directive when the subtarget supports xnack. Match that behavior in the
disassembler so the round-trip is consistent and gfx11/gfx12 descriptors
no longer carry a spurious directive.
As a guard against a malformed binary, if the object's ELF e_flags
erroneously select xnack "on" for a target that does not support xnack,
still print the directive so the invalid state remains visible in the
disassembly rather than being silently dropped.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
NAS-141994 / 26.0.0-RC.1 / Export ServiceOptions from the v26_0_0 API module (#19437)
## Problem
`plugins/smb_/sid.py` imports `ServiceOptions` from
`middlewared.api.current`, but `api/v26_0_0/service.py` defines the
class without listing it in `__all__`. Since `v26_0_0/__init__.py` pulls
the module in with `from .service import *`, the name never gets rebound
and the import raises `ImportError` at plugin load. `load_modules`
doesn't guard `importlib.import_module`, so this is fatal — middlewared
won't start. It only shows up on 26 because master's `api/current.py`
points at `v27_0_0`, whose `__all__` does export the name.
## Solution
Added `ServiceOptions` to `v26_0_0/service.py`'s `__all__`, matching
v27. An AST sweep of every name imported from `middlewared.api.current`
across the tree confirms this was the only one missing from v26's
exports, so nothing else is queued behind it. `ServiceUpdate` is also
unexported relative to v27, but nothing imports it through
`api.current`, so I left it alone.
