** No longer affects: pmix (Ubuntu)
** Description changed:
+ SUMMARY: On Ubuntu 26.04, hwloc's GL plugin (hwloc_gl.so, in
+ libhwloc-plugins) blocks forever in an X11 connection attempt during
+ topology discovery. Plain "lstopo" never returns, and every Open MPI program
+ launched directly — without mpirun — hangs inside MPI_Init_thread before
+ reaching user code. Upstream hwloc fixed this in 2.14 by disabling the GL
+ component by default; resolute ships 2.13.0-2. Requesting an SRU to backport
+ that default. Sole working mitigation: HWLOC_COMPONENTS=-gl.
+
[Impact]
- On a default Ubuntu 26.04 desktop install (Wayland session), any process that
- performs hwloc topology discovery with I/O devices enabled blocks FOREVER in
- connect() to an X display socket, inside hwloc's GL plugin
- (/usr/lib/x86_64-linux-gnu/hwloc/hwloc_gl.so). There is no timeout, no error
- message, and in the shipped hwloc version no runtime knob dedicated to this
- plugin — the process simply hangs.
+ Any process performing hwloc topology discovery with I/O devices enabled
+ hangs indefinitely inside XOpenDisplay, called from hwloc's GL plugin during
+ hwloc_topology_load. No error, no output, no timeout observed.
- The simplest demonstration is that plain "lstopo", with no arguments, never
- returns.
-
- The most prominent victim is Open MPI. Every MPI program launched directly
- ("./app", i.e. singleton init, which the MPI standard supports and which
- worked on every previous Ubuntu release) hangs inside MPI_Init /
- MPI_Init_thread before reaching user code. Programs launched via
- "mpirun -n N app" are NOT affected, because the MPI processes then receive
- their topology pre-computed from the PRRTE daemon via PMIx instead of running
- hwloc discovery themselves. This asymmetry hides the bug from most testing
- (anything exercised under mpirun passes) while breaking direct invocation,
- scripted single-process runs, test suites, and mpi4py-style usage.
+ Open MPI is the significant victim. Singleton init ("./app") — supported by
+ the MPI standard, and working on 24.04 — hangs before user code runs.
+ "mpirun -n N app" is unaffected (verified), because those processes get their
+ topology from the PRRTE daemon via PMIx rather than running hwloc discovery
+ themselves. That asymmetry hides the bug from any testing done under mpirun
+ while breaking direct invocation, scripted single-process runs and test
+ suites.
Aggravating factors:
- * The hang occurs on a fully working NVIDIA setup with the proprietary
- driver installed — this is not a missing-hardware or missing-driver
- situation. The GL plugin's sole purpose is NVIDIA NV-CONTROL display
- locality, and it blocks even where that hardware is present and healthy.
- * libhwloc-plugins is installed on any system with Open MPI, because
- libopenmpi40 and libpmix2t64 both hard-Depend on it (see the secondary
- issue at the bottom). It is therefore active in every MPI process.
- * This is a regression relative to Ubuntu 24.04 LTS, on a brand-new LTS with
- years of support ahead, and it is present on FRESH installs — in no way an
- artefact of upgrading. Confirmed on two distinct hardware configurations,
- both clean 26.04 installs (see Reproducibility).
- * DISPLAY is irrelevant: the plugin synthesises its own display names, so
- users cannot dodge this by unsetting DISPLAY (verified below).
- * The failure mode is a silent hang with no diagnostic output; identifying
- the cause required attaching gdb to the stuck process.
+ * Verified on two distinct hardware configurations, both clean
+ (non-upgraded) 26.04 installs: a defect of the released packages, not an
+ upgrade artefact.
+ * The plugin is loaded into every MPI process, and cannot be removed:
+ libopenmpi40 and libpmix2t64 both hard-Depend on libhwloc-plugins (see
+ Secondary issue).
+ * No environment-based escape. The hang persists with DISPLAY unset, with
+ XAUTHORITY unset, and with a completely empty environment (env -i) — all
+ verified.
+ * A silent hang with no diagnostic output; diagnosis required attaching gdb.
+ * A regression from 24.04 on a new LTS with years of support remaining.
- Upstream hwloc has already acknowledged and fixed exactly this problem: as of
- hwloc 2.14, the GL component is disabled by default and must be explicitly
- opted into with HWLOC_GL=1, because (per the upstream documentation) the code
- "may hang when trying to connect to the X server". Resolute ships 2.13.0-2 —
- one release short of the fix, so it has the hang without the remedy.
-
- Requesting an SRU that backports the upstream default-off behaviour (a small,
- self-contained change) or updates to a 2.14+ point release.
+ Upstream hwloc addressed exactly this in 2.14: the GL component is now
+ disabled unless HWLOC_GL=1 is set, because (per upstream documentation) the
+ code "may hang when trying to connect to the X server". Resolute ships
+ 2.13.0-2, one release short of that change.
[Test Plan]
- IMPORTANT PRECONDITION: the reproducer must be run from a terminal emulator
- running INSIDE the graphical session. A text console on another VT
- (Ctrl+Alt+F2, i.e. no graphical session in that login) does NOT reproduce the
- hang — verified. Testing from a VT, and most likely from an SSH login or a
- headless VM console (not verified), will therefore show no problem even on an
- affected system. Note that this is not simply a matter of DISPLAY being
- unset: unsetting DISPLAY in a graphical-session terminal still hangs (see
- [Other Info]), so the differentiating factor is something else about the
- graphical session context and has not yet been isolated.
+ PRECONDITION: run from a terminal inside the graphical session. Verified: the
+ hang does NOT occur from a text console on another VT (Ctrl+Alt+F2). It is
+ not an environment variable that differs — see the verified results below.
- All steps below assume a default Ubuntu 26.04 desktop install with an active
- graphical (Wayland) session, using its terminal.
+ 1. PRIMARY, no compilation required:
- 1. Without MPI (minimal reproducer). Note that lstopo lives in the "hwloc"
- package, which is not part of a default install:
+ sudo apt install hwloc # lstopo is not installed by default
+ timeout 15 lstopo >/dev/null 2>&1; echo $?
- sudo apt install hwloc
- timeout 15 lstopo > /dev/null; echo $?
+ Affected: 124 (i.e. still running when killed; left unbounded, it did not
+ return after several minutes). Fixed: expected 0, returning promptly.
- Affected system: prints "124" (killed by the timeout; without it, lstopo
- never returns — observed for many minutes, and indefinitely in the MPI
- case).
- Fixed package: prints "0" and returns essentially instantly.
-
- Plain "lstopo" with no arguments is sufficient: lstopo enables I/O device
- discovery by default, so no --whole-io or other flag is needed. Verified
- on the affected system that "lstopo" returns 124 while
- "HWLOC_COMPONENTS=-gl lstopo" returns 0 immediately, in the same shell.
-
- Optional cross-check, to rule out lstopo's own graphical X11 support
- rather than the GL plugin: repeat with the non-X build of the tools from
- hwloc-nox. Note hwloc-nox and hwloc conflict, so this replaces hwloc;
- confirm the binary name with "dpkg -L hwloc-nox":
-
- sudo apt install hwloc-nox
- timeout 15 lstopo-no-graphics > /dev/null; echo $?
-
- The backtraces already settle the point — the blocking call sits inside
- hwloc_gl.so, below XOpenDisplay and reached from hwloc_topology_load, i.e.
- in library code that lstopo merely calls into. The MPI reproducer reaches
- the same frames with no lstopo in the picture at all.
-
- 2. With MPI (the real-world symptom). hello.c:
+ 2. SECONDARY, real-world symptom. Verified with a production Open MPI
+ application: run directly it hangs in MPI_Init_thread (backtrace below);
+ "mpirun -n 1" of the same binary works. Equivalent minimal program for
+ verification:
#include <mpi.h>
- int main(void) {
- int tl;
+ int main(void) { int tl;
MPI_Init_thread(NULL, NULL, MPI_THREAD_MULTIPLE, &tl);
- MPI_Finalize();
- return 0;
- }
+ MPI_Finalize(); return 0; }
mpicc hello.c -o hello
- ./hello # affected: hangs forever; fixed: exits 0
- mpirun -n 1 ./hello # works before and after (control case)
+ ./hello # affected: hangs; fixed: exits 0
+ mpirun -n 1 ./hello # control: works either way
- 3. Opt-in still functional after the fix (upstream 2.14 semantics):
-
- HWLOC_GL=1 lstopo > /dev/null
-
- should re-enable the GL probe, and may therefore hang again on affected
- configurations — that is the expected, documented opt-in behaviour.
+ 3. Opt-in still available on the fixed package, per hwloc 2.14 semantics:
+ "HWLOC_GL=1 lstopo" should re-enable the GL probe.
[Where problems could occur]
- The backport changes the default component set: topologies will no longer
- contain GL OS device objects (names like ":0.0") unless HWLOC_GL=1 is set.
- Only software using the hwloc/gl.h interoperability API — NVIDIA
- display-to-GPU locality, e.g. some visualisation schedulers — would notice,
- and the environment variable restores the previous behaviour. CUDA, NVML,
- OpenCL and PCI discovery are unaffected, being separate components. The
- resulting default matches upstream hwloc >= 2.14, so this does not diverge
- from where later Ubuntu releases will land anyway. Risk is low and confined
- to a feature that is recoverable by opt-in.
+ Topologies will no longer contain GL OS device objects (such as ":0.0")
+ unless HWLOC_GL=1 is set. Only software using the hwloc/gl.h interoperability
+ API for NVIDIA display-to-GPU locality would notice, and the environment
+ variable restores the previous behaviour. The resulting default matches
+ upstream hwloc >= 2.14, so this does not diverge from where later Ubuntu
+ releases land anyway.
[Other Info]
- * HWLOC_GL=0 is silently accepted and IGNORED by the shipped version: the
- variable only acquires meaning in 2.14, where it is the opt-IN. The
- documented upstream mitigation therefore does not exist in resolute.
- Verified: "HWLOC_GL=0 lstopo" still hangs.
+ Verified results, graphical-session terminal, 15 s timeout (124 = hang):
- * The only working runtime mitigation on the shipped version is the generic
- component blacklist, HWLOC_COMPONENTS=-gl (verified; see Workarounds).
- That mechanism has existed since hwloc 1.6.0, so it is dependable, but it
- is undiscoverable for a user facing a silent hang.
+ timeout 15 lstopo -> 124
+ env -u DISPLAY timeout 15 lstopo -> 124
+ env -u XAUTHORITY timeout 15 lstopo -> 124
+ env -i /usr/bin/timeout 15 /usr/bin/lstopo -> 124
+ HWLOC_COMPONENTS=-gl timeout 15 lstopo -> 0
+ (same lstopo invocation from a VT text console: does not hang)
- * DISPLAY alone does not explain the trigger, and the trigger is not fully
- isolated. Within a graphical-session terminal, lstopo hangs identically
- whether DISPLAY=:0 is exported by the session or DISPLAY is unset entirely
- (both return 124 under a 15 s timeout) — consistent with the GL backend
- synthesising candidate display names of the form ":port.device" itself
- rather than honouring DISPLAY. Yet the same command run from a text console
- on another VT (Ctrl+Alt+F2), where DISPLAY is likewise unset, does NOT
- hang. So something else about the graphical session context is required.
- XAUTHORITY is an obvious candidate but this has not been confirmed. Either
- way, a user cannot avoid the hang by unsetting DISPLAY in the environment
- where they actually work.
+ * HWLOC_GL=0 does not help: that variable only acquires meaning in 2.14,
+ where it is the opt-IN. Verified — "HWLOC_GL=0 lstopo --whole-io -" was
+ left running for several minutes without returning. So the documented
+ upstream mitigation does not exist in resolute.
+ * HWLOC_COMPONENTS=-gl is the only working mitigation found (verified for
+ both lstopo and the MPI application). It has existed since hwloc 1.6.0,
+ but is undiscoverable for a user facing a silent hang.
+ * Upstream: the hang warning and the HWLOC_GL=1 opt-in appear in
+ include/hwloc/gl.h from hwloc v2.14, and in the current upstream
+ "Components and plugins" documentation. Related upstream issue in the same
+ backend and XOpenDisplay path, milder symptom:
+ https://github.com/open-mpi/hwloc/issues/483
- * Possibly relevant to why connect() blocks rather than failing fast: this
- system has two X socket files but only one X server process. Xwayland is
- running on :0, yet /tmp/.X11-unix/ contains both X0 and X1 (see
- Environment). A connect() to a Unix socket whose server is absent normally
- fails immediately with ECONNREFUSED, so an indefinite block suggests
- either a listener that never accepts or a socket left behind by a departed
- server. Offered as an observation only — the hwloc-side defect stands
- regardless, which is precisely the reasoning upstream applied when they
- disabled the component by default.
+ Backtrace (full gdb "thread apply all bt" of a hung plain lstopo attached as
+ lstopo-hang-backtrace.txt; the excerpt below is from the hung MPI
+ application on the same system, captured the same way):
- * Related upstream issue (same backend, same XOpenDisplay path, milder
- symptom): https://github.com/open-mpi/hwloc/issues/483
- Upstream default-off change: first appears in include/hwloc/gl.h as of
- hwloc v2.14 ("This code may hang when trying to connect to the X server.
- Hence the GL component is disabled unless HWLOC_GL=1 in the environment.")
- The same wording is in the current upstream "Components and plugins"
- documentation.
+ #3 __libc_connect (...) <- blocked here
+ #4 xcb_connect_to_display_with_auth_info () libxcb.so.1
+ #6 XOpenDisplay () libX11.so.6
+ #7 ?? () hwloc/hwloc_gl.so
+ #9 hwloc_topology_load () libhwloc.so.15
+ #10 opal_hwloc_base_get_topology () libopen-pal.so.80
+ #16-#18 ompi_mpi_instance_init / ompi_mpi_init libmpi.so.40
+ #19 PMPI_Init_thread () libmpi.so.40
+ #20 <application>
- * Ubuntu has defaulted to a Wayland session since 25.10, which is the likely
- reason this surfaced now: the GL plugin has always probed X during topology
- load, but under Xorg sessions the probe completed or failed quickly. A
- hardware-discovery library that blocks indefinitely on X inside its init
- path, with no timeout, is the defect either way.
+ All other threads idle (PMIx progress thread in epoll_wait, OpenBLAS pool in
+ pthread_cond_wait) — PMIx and runtime bring-up completed normally.
-
--------------------------------------------------------------------------------
- Steps to reproduce
-
--------------------------------------------------------------------------------
- 1. Install Ubuntu 26.04 and log into the default desktop session. A fresh
- install is sufficient — this is NOT specific to upgraded systems. Use a
- terminal emulator inside that graphical session: a text console on another
- VT does not reproduce the hang (see the precondition in [Test Plan]).
- 2. Build any Open MPI application against the distro Open MPI.
- 3. Run it directly: ./App -> hangs at MPI_Init_thread(...)
- Run it as: mpirun -n 1 ./App -> runs normally.
- 4. sudo apt install hwloc, then run: lstopo
- -> also hangs (no MPI involved).
+ Reproducibility: 100% on both configurations tested, each a fresh/clean 26.04
+ install with no third-party or self-built hwloc/MPI:
+ A. AMD Ryzen 9 9950X + NVIDIA GeForce RTX 5060 Ti (GB206)
+ B. AMD Ryzen 9 7950X + NVIDIA GeForce RTX 4060 Ti
+ Both have an NVIDIA discrete GPU alongside AMD integrated graphics; systems
+ without an NVIDIA GPU were not tested.
- Expected: singleton launch initialises just as "mpirun -n 1" does, as it did
- on 24.04 and every earlier release; lstopo returns promptly.
+ SECONDARY ISSUE: the plugin cannot be declined without removing MPI
- Actual: indefinite hang, no output, no error.
+ hwloc's own packaging leaves it optional — libhwloc15 only Recommends
+ libhwloc-plugins. The hard dependency comes from the MPI side (relevant lines
+ only, from "apt-cache show libhwloc15 libpmix2t64 libopenmpi40"):
- Reproducibility: 100% reproducible, with the distro packages alone, on both
- hardware configurations tested. Every system was a FRESH/CLEAN Ubuntu 26.04
- install — no upgrade path, no configuration carried over from a previous
- release, no self-built or third-party hwloc/MPI involved. The two
- configurations are:
-
- A. AMD Ryzen 9 9950X + NVIDIA GeForce RTX 5060 Ti (GB206)
- B. AMD Ryzen 9 7950X + NVIDIA GeForce RTX 4060 Ti
-
- Both have an NVIDIA discrete GPU alongside AMD integrated graphics. Systems
- with no NVIDIA GPU at all were not tested; based on the code path the probe
- should run there too, but this report does not claim it.
-
-
--------------------------------------------------------------------------------
- Backtrace of the hung process
-
--------------------------------------------------------------------------------
- Attached: full gdb "thread apply all bt" of a hung plain "lstopo" — no MPI and
- no user application involved, reproducible with distro packages alone.
-
- The stack below is from the original discovery, a hung Open MPI singleton
- launch, and shows how the same blocking call is reached from MPI_Init_thread.
- Thread 1 (main thread), obtained with
- "gdb -p <pid> -batch -ex 'thread apply all bt'":
-
- #3 __libc_connect (...) <- blocked here
- #4 xcb_connect_to_display_with_auth_info () libxcb.so.1
- #5 _XConnectXCB () libX11.so.6
- #6 XOpenDisplay () libX11.so.6
- #7 ?? () hwloc/hwloc_gl.so
- #8 ?? () libhwloc.so.15
- #9 hwloc_topology_load () libhwloc.so.15
- #10 opal_hwloc_base_get_topology () libopen-pal.so.80
- #11-#15 mca_base_framework_open (...) libopen-pal.so.80
- #16 ?? () libmpi.so.40
- #17 ompi_mpi_instance_init () libmpi.so.40
- #18 ompi_mpi_init () libmpi.so.40
- #19 PMPI_Init_thread () libmpi.so.40
- #20 <application>
-
- All other threads are idle — the PMIx progress thread in epoll_wait, an
- OpenBLAS worker pool in pthread_cond_wait — i.e. PMIx and runtime bring-up
- completed normally. The hang is exclusively the GL plugin's X connect.
-
-
--------------------------------------------------------------------------------
- Root cause
-
--------------------------------------------------------------------------------
- hwloc's GL backend (topology-gl.c, shipped as hwloc_gl.so in
- libhwloc-plugins) queries the NVIDIA NV-CONTROL X extension to annotate GPU
- display locality. During hwloc_topology_load with I/O discovery enabled —
- which Open MPI's opal_hwloc_base_get_topology performs, and which lstopo
- enables by default — it calls XOpenDisplay on candidate display names it
- constructs itself. On this system that connect() never completes. In hwloc
- 2.13 the plugin runs unconditionally: no dedicated runtime disable, no
- timeout, no diagnostic.
-
-
--------------------------------------------------------------------------------
- Workarounds for affected users
-
--------------------------------------------------------------------------------
- 1. Per-process / per-shell (both verified working):
-
- HWLOC_COMPONENTS=-gl ./App
- HWLOC_COMPONENTS=-gl lstopo
-
- 2. NOT workarounds on this version: HWLOC_GL=0 (silently ignored), unsetting
- DISPLAY (no effect within a graphical session), and removing
- libhwloc-plugins (would remove the MPI stack — see below). Running from a
- text console on another VT does avoid the hang, but that is a property of
- the reproduction environment rather than a usable workaround for anyone
- working in a desktop session.
-
-
--------------------------------------------------------------------------------
- SECONDARY ISSUE: the X-linked plugin cannot be declined without removing MPI
-
--------------------------------------------------------------------------------
- hwloc's own packaging is correct here — libhwloc15 only Recommends the plugin
- package. The hard dependency comes from the MPI side:
+ Package: libhwloc15 (2.13.0-2)
+ Recommends: libhwloc-plugins
+ Package: libpmix2t64 (6.0.0+really5.0.9-3build1)
+ Depends: ..., libhwloc15 (>= 2.12.2), ..., libhwloc-plugins
+ Package: libopenmpi40 (5.0.10-1)
+ Depends: ..., libhwloc15 (>= 2.13.0), libpmix2t64 (>= 6.0.0+really5.0.9),
+ ..., libhwloc-plugins
$ dpkg -S /usr/lib/x86_64-linux-gnu/hwloc/hwloc_gl.so
libhwloc-plugins:amd64: /usr/lib/x86_64-linux-gnu/hwloc/hwloc_gl.so
- $ apt-cache show libhwloc15 libpmix2t64 libopenmpi40 \
- | grep -E '^(Package|Version|Depends|Recommends)'
- Package: libhwloc15
- Version: 2.13.0-2
- Recommends: libhwloc-plugins
- Depends: libc6 (>= 2.38), libudev1 (>= 183)
- Package: libpmix2t64
- Version: 6.0.0+really5.0.9-3build1
- Depends: libc6 (>= 2.38), libevent-core-2.1-7t64 (>= 2.1.8-stable),
- libevent-pthreads-2.1-7t64 (>= 2.1.8-stable), libhwloc15 (>= 2.12.2),
- libmunge2 (>= 0.5.8), zlib1g (>= 1:1.2.0), libhwloc-plugins
- Package: libopenmpi40
- Version: 5.0.10-1
- Depends: libc6 (>= 2.38), libevent-core-2.1-7t64 (>= 2.1.8-stable),
- libevent-pthreads-2.1-7t64 (>= 2.1.8-stable), libfabric1 (>= 2.0.0),
- libgcc-s1 (>= 3.0), libhwloc15 (>= 2.13.0), libnl-3-200 (>= 3.11.0),
- libpmix2t64 (>= 6.0.0+really5.0.9), libpsm2-2 (>= 10.3-37),
- libucc1 (>= 1.7.0~rc1), libucx0, libhwloc-plugins
+ So "apt remove libhwloc-plugins" would take libopenmpi40 and libpmix2t64 with
+ it — the entire MPI stack. There is no route through apt to decline a plugin
+ that is loaded into every MPI process. Requests, complementary to the
+ default-off backport: split hwloc_gl.so into its own binary package (there is
+ precedent in libhwloc-contrib-plugins), or stop shipping it. Happy to file
+ this separately against openmpi/pmix if preferred.
- Consequences:
- * "apt remove libhwloc-plugins" would remove libopenmpi40 and libpmix2t64
- with it, i.e. the entire MPI stack. There is no supported way to decline
- an X11-connecting plugin that is dlopen'd into every MPI process, and no
- way to do so through apt at all.
- * The plugin is installed and active on headless servers and HPC compute
- nodes as readily as on desktops. An hwloc-nox package exists for the
- command-line utilities, but there is no equivalent for the plugin package.
+ Environment (configuration A)
- Note that those Depends are presumably not gratuitous: libhwloc-plugins
- bundles the GL plugin together with plugins that MPI does legitimately want
- for locality (PCI/CUDA/NVML-class discovery). That is precisely why the right
- remedy is to separate the X-dependent plugin rather than to weaken the MPI
- dependencies:
+ Ubuntu 26.04 LTS (resolute); XDG_SESSION_TYPE=wayland; DISPLAY=:0
+ hwloc / libhwloc15 / libhwloc-plugins 2.13.0-2
+ openmpi-bin / libopenmpi40 5.0.10-1
+ libpmix2t64 6.0.0+really5.0.9-3build1
+ All from resolute/universe, release pocket: no updates, PPAs or local
+ builds. lstopo --version reports 2.13.0.
- a) Split hwloc_gl.so into its own binary package — there is precedent in
- libhwloc-contrib-plugins — so that it can be omitted without touching
- PCI discovery or the MPI stack; or
- b) failing that, stop building the gl plugin for Ubuntu, since its only
- function is NVIDIA NV-CONTROL display locality, which is of marginal
- value on the systems that install it by default.
+ AMD Ryzen 9 9950X (16C/32T, 1 NUMA node)
+ 01:00.0 VGA: NVIDIA GB206 [GeForce RTX 5060 Ti]
+ 74:00.0 VGA: AMD Granite Ridge [Radeon Graphics]
- Happy to split this section into a separate bug against openmpi/pmix if the
- maintainers prefer.
+ Xwayland running on :0 (no Xorg process). /tmp/.X11-unix/ contains X0 and
+ X1.
-
--------------------------------------------------------------------------------
- Environment
-
--------------------------------------------------------------------------------
- $ lsb_release -rd
- Description: Ubuntu 26.04 LTS
- Release: 26.04
+ Note: lstopo itself is not installed by default, but the defect is present on
+ a default install regardless, because libhwloc-plugins arrives with the Open
+ MPI runtime libraries.
- $ lstopo --version
- lstopo 2.13.0
+ Regression baseline: the same application and workflow ran correctly on
+ Ubuntu 24.04 (hwloc 2.10.0-1build1, Open MPI 4.1.6) for years.
- $ apt-cache policy hwloc libhwloc15 libhwloc-plugins openmpi-bin libopenmpi40
libpmix2t64
- hwloc: Installed: 2.13.0-2
(resolute/universe)
- libhwloc15: Installed: 2.13.0-2
(resolute/universe)
- libhwloc-plugins: Installed: 2.13.0-2
(resolute/universe)
- openmpi-bin: Installed: 5.0.10-1
(resolute/universe)
- libopenmpi40: Installed: 5.0.10-1
(resolute/universe)
- libpmix2t64: Installed: 6.0.0+really5.0.9-3build1
(resolute/universe)
-
- All from the release pocket; no updates, no PPAs, no local builds.
- hwloc 2.13.0 is one upstream release short of 2.14, where the GL component
- was disabled by default.
-
- $ dpkg -S /usr/lib/x86_64-linux-gnu/hwloc/hwloc_gl.so
- libhwloc-plugins:amd64: /usr/lib/x86_64-linux-gnu/hwloc/hwloc_gl.so
-
- $ echo $XDG_SESSION_TYPE
- wayland
-
- $ echo $DISPLAY
- :0
-
- $ pgrep -a Xwayland
- 10464 /usr/bin/Xwayland :0 -rootless -noreset -accessx -core -auth
- /run/user/1000/.mutter-Xwaylandauth.IXZNT3 -listenfd 4 -listenfd 5
- -displayfd 6 -initfd 7 -byteswappedclients -enable-ei-portal
-
- $ pgrep -a Xorg
- (no output — no Xorg server running)
-
- $ ls -l /tmp/.X11-unix/
- total 0
- srwxrwxr-x 1 roy roy 0 Aug 4 08:43 X0
- srwxrwxr-x 1 roy roy 0 Aug 4 08:43 X1
-
- (note: two socket files, but only one X server process, on :0 — see the
- observation in [Other Info])
-
- $ lspci | grep -Ei 'vga|3d|display'
- 01:00.0 VGA compatible controller: NVIDIA Corporation GB206 [GeForce RTX 5060
Ti] (rev a1)
- 74:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Granite Ridge [Radeon Graphics] (rev c1)
-
- $ lscpu | grep -E 'Model name|^CPU\(s\)|Socket|Core|Thread|NUMA node\(s\)'
- Model name: AMD Ryzen 9 9950X 16-Core Processor
- CPU(s): 32
- Thread(s) per core: 2
- Core(s) per socket: 16
- Socket(s): 1
- NUMA node(s): 1
-
- Reproduction results on this machine, same shell, 15 s timeout each:
-
- $ timeout 15 lstopo >/dev/null 2>&1; echo $?
- 124 <- hangs
-
- $ env -u DISPLAY timeout 15 lstopo >/dev/null 2>&1; echo $?
- 124 <- still hangs; DISPLAY is irrelevant
-
- $ HWLOC_COMPONENTS=-gl timeout 15 lstopo >/dev/null 2>&1; echo $?
- 0 <- succeeds immediately with GL blacklisted
-
- Note on tooling: lstopo is not present on a default install — the "hwloc"
- package must be added to run the non-MPI reproducer. The DEFECT is present on
- a default install regardless, because libhwloc-plugins (which contains
- hwloc_gl.so) arrives automatically with the Open MPI runtime libraries.
-
- Regression baseline: the identical application and workflow ran correctly on
- Ubuntu 24.04 (hwloc 2.10.0-1build1, Open MPI 4.1.6) for years. It fails on
- 26.04 (hwloc 2.13.0-2, Open MPI 5.0.10-1) on both upgraded and freshly
- installed systems.
+ Disclosure: this investigation and report were prepared with AI assistance
+ (Anthropic's Claude). Every command output and reproduction result quoted
+ above was executed by the reporter on the affected systems; upstream
+ references were checked against hwloc's source headers and documentation.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2162940
Title:
hwloc GL plugin hangs in XOpenDisplay() during topology load: plain
"lstopo" and every Open MPI singleton launch hang on 26.04 (fixed
upstream in hwloc 2.14)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/hwloc/+bug/2162940/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
