Failures on November 6, 2026 — times are PST (UTC−08:00):
08:11:35–36: kernel linked-list corruption followed by a NULL-pointer Oops in remove_wait_queue while handling a Python process.
08:31:17: linked-list corruption in multiple process contexts, including VS Code, followed by an Oops in plist_add / __futex_queue.
08:41:17 onward: five kernel Oops involving Bluetooth, D-Bus, and device workers. CPUs 5 and 6 subsequently produced watchdog soft-lockup reports reaching 161 seconds.
Across these three episodes, the journals contain seven kernel Oops, eight linked-list corruption messages, and fourteen CPU soft-lockup reports. All three episodes occurred on the same 1025 kernel build.
Recovery:
I booted the previous 1019 kernel at 08:50:06. No new kernel-corruption episode was detected during the subsequent observation period. This is preliminary observation, not a completed controlled stability test.
Additional context:
• No NVIDIA Xid, kernel OOM kill, or disk I/O failure was recorded in the reviewed morning window.
• Installed nvidia-spark-initcall-bl is 1.0-1; power_wrap_init is not blacklisted.
• NVIDIA platform repositories are disabled and reference Noble, while the enabled Ubuntu repositories reference Resolute.
• No kernel vmcore was captured because crash-memory reservation was zero.
• The original source of the kernel-memory corruption remains unproven.
Related investigation:
Questions:
Is this 1025 corruption pattern a tracked regression?
Is there a fixed kernel or recommended workaround?
Does nvidia-spark-initcall-bl 1.0-2 address these corruption/lockup symptoms, or only display-triggered resets?
What is the supported NVIDIA platform-update path for this Ubuntu 26.04 installation?
The failures occurred during normal desktop use, including VS Code, with background services running. I haven’t confirmed a failure while the unit was completely idle.
The three recorded kernel-corruption episodes began approximately 3 minutes 28 seconds, 11 minutes 7 seconds, and 7 minutes 44 seconds after their respective boots. All three used 7.0.0-1025-nvidia.
I don’t yet have a reliable workload trigger or controlled idle-versus-load comparison. After reverting to 7.0.0-1019-nvidia, no further kernel-corruption events appeared during the initial observation period.
Can you check “cat /proc/cmdline" and "apt-cache policynvidia-spark-initcall-bl”
Without the nvidia-spark-initcall-bl 1.0-2 fix, your system will become unstable with certain display.
Since you are on Ubuntu 26.04, you won’t automatically get the nvidia-spark-initcall-bl 1.0-2 fix.
You will need to manually add the blacklist in the kernel boot arg,
initcall_blacklist=tegra234_cbb_init,power_wrap_init
tegra234_cbb_init should be already there. Just need to add power_wrap_init
I checked the system. It currently has nvidia-spark-initcall-bl 1.0-1; version 1.0-2 is not available. The kernel already has initcall_blacklist=tegra234_cbb_init, but power_wrap_init is missing. Please confirm the recommended persistent GRUB change to add power_wrap_init.
Yes, you need to persistently have the power_wrap_init workaround in your grub. Let me know if you need step by step instruction for modifying the GRUB config.
Thanks. I’ve already added power_wrap_init persistently to my GRUB configuration alongside tegra234_cbb_init, and confirmed it is active in /proc/cmdline. I’ve also installed nvidia-spark-initcall-bl version 1.0-2. I’m monitoring the system now for further freezes or kernel errors.