Hi Anthony, I found your CPU-affinity investigation on CID 202505-36753 while researching what appears to be a closely related failure on a separate Dell Pro Max 18 Plus MB18250 with the same Core Ultra 9 285HX. Your report is the closest independent match I have found.
Our failure also localizes most strongly to the E-core cluster containing CPUs 16-19, especially logical CPU 19. It was first exposed by Node/PGlite, but the investigation has since reduced it beyond PGlite, Node, V8, and WebAssembly: - Live GDB captures on CPU 19 repeatedly stop on ordinary register-relative loads/stores or RMWs with clean instruction bytes and register values. The intended address is mapped, but `si_addr`/CR2 is exactly the intended effective address plus `0x40000000000` (`2^42`). For example, `addl $1,0x1c0(%r13)` with `r13=0x6720080` should access `0x6720240`, but CR2 is `0x40006720240`. - A dependency-free native C churn harness also produced kernel oopses on CPU 19, so Node/V8/Wasm are not required. In the cleanest oops, syscall entry was executing `push %r14`; `RSP-8` was `ffffd20d8b2d3f60`, while CR2 was `ffffd60d8b2d3f60`—again exactly bit 42 added to the architecturally intended stack address. - The problem persists on Dell BIOS 3.3.2 dated 2026-08-03 and Intel microcode `0x122`, the latest public microcode for Arrow Lake-S/HX B0 (`06-c6-02/82`). - External load on P-cores greatly increases the CPU-19 failure rate. Disabling turbo or lowering frequency strongly suppresses it in the samples collected so far, although that does not distinguish CPU silicon from board power delivery or firmware voltage behavior. The repository, reproduction tools, full measurements, and verbatim kernel oopses are here: https://github.com/gadicc/node-pglite-wasm-sigsegv-repro The kernel captures are here: https://github.com/gadicc/node-pglite-wasm-sigsegv- repro/blob/main/captures/kernel-oops-cpu19-20260818.txt Your report does not include enough of the original `post_alloc_hook` oops to determine whether it has the same `+2^42` fault-address signature, so I do not want to claim a common root cause prematurely. However, the exact model and CPU SKU, moving GCC failures, kernel-mode page fault, CPUs 16-19 localization, and CPU 19 emphasis make the correspondence unusually strong. If CID 202505-36753 or its original logs are still available, would it be possible to do either of the following? 1. Retrieve the complete CPU-19 `post_alloc_hook` oops, especially CR2, RSP, RIP, instruction bytes, and general-purpose registers. That may let us calculate whether its fault address also differs from the intended address by one high bit. 2. Retest that machine on current BIOS/microcode, ideally with one of the dependency-free reproducers pinned to CPU 19. `mini-wasm-churn.mjs` is the practical high-rate userspace trigger; `repro-c --mode churn-mem` removes Node/V8/Wasm but can cause a kernel oops or wedge, so it carries an explicit warning and should only be used where a forced reboot is acceptable. I have also reported the original symptom upstream as [nodejs/node#64500](https://github.com/nodejs/node/issues/64500) and [electric-sql/pglite#1053](https://github.com/electric-sql/pglite/issues/1053), but the accumulated evidence now points below those software layers. Thank you for publishing the affinity results—they provide a very valuable independent comparison point. Gadi ** Bug watch added: github.com/nodejs/node/issues #64500 https://github.com/nodejs/node/issues/64500 ** Bug watch added: github.com/electric-sql/pglite/issues #1053 https://github.com/electric-sql/pglite/issues/1053 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2158237 Title: nvidia-dkms-580-open attempts a DKMS build despite prebuilt linux- modules-nvidia-580-open packages being installed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-580/+bug/2158237/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
