Skip to content

SIGSEGV in sysfs_find_adapter when a DRM card's sysfs entry is present but unreadable (blocked, not removed, GPU) #641

Open
Open
SIGSEGV in sysfs_find_adapter when a DRM card's sysfs entry is present but unreadable (blocked, not removed, GPU)#641
Labels
Fixedbugenhancement

Description

@plastininikolay
plastininikolay
opened on Sep 24, 2026

SIGSEGV in sysfs_find_adapter when a DRM card's sysfs entry is present but unreadable (blocked, not removed, GPU)

Disclosure: This report was drafted with the assistance of Claude Code (Anthropic), which investigated the crash (systemd/coredumpctl/gdb) and drafted this text. I (the reporter) reviewed and confirm the findings below.

Summary

ddcutil detect (and libddcutil as used by KDE Plasma's powerdevil) reliably segfaults in sysfs_find_adapter() when /sys/class/drm/ contains an entry for a GPU whose PCI device is present in sysfs but unreadable (blocked, not cleanly removed). In my case the discrete NVIDIA GPU is dynamically blocked by cardwire (a GPU-switcher that uses eBPF LSM hooks to deny access to a GPU's PCI device) whenever the laptop is in "Integrated" mode. card0, card0-eDP-2, card0-HDMI-A-2 show up as broken directory entries (ls shows l??????????, stat/readlink → ENOENT) while the working iGPU is card1.

Specifically: my system has Secure Boot enabled, which puts the kernel in lockdown and prevents cardwire's eBPF program from using bpf_probe_write_user, so it falls back to a "weakened" blocking mode. In that mode the GPU's PCI device is blocked but not cleanly unbound/removed — its sysfs/PCI entries stay listed while reads on them fail (this is documented behavior of cardwire itself, see cardwire PR #266, which I also authored: "a blocked GPU's sysfs entries stay listed and unreadable, so lspci shows it as Illegal Vendor ID ffff"). This present-but-broken sysfs state is apparently what sysfs_find_adapter()/check_connector_reliability() don't handle — code named is_sysfs_reliable_for_driver()/check_sysfs_reliability() suggests ddcutil already tries to detect exactly this kind of unreliable-sysfs situation, but crashes while doing so instead of falling back gracefully.

Because the dGPU stays blocked in this state for the whole session (not just transiently), this is a persistent, 100%-reproducible crash on every ddcutil detect/libddcutil init while in that mode — not a one-off race. (On a system without Secure Boot, cardwire's normal eBPF blocking may behave differently — e.g. a cleaner absence rather than a present-but-unreadable device — I have not tested that case.)

Environment

  • ddcutil: 2.2.1 (Fedora package ddcutil-2.2.1-3.fc44, built Jan 16 2026, libdrm support enabled, USB support enabled)
  • libddcutil: 2.2.1-3.fc44
  • Distro: Fedora Linux 44 (KDE Plasma Desktop Edition)
  • Kernel: 7.2.7-200.fc44.x86_64
  • Consumer: KDE Plasma powerdevil (/usr/libexec/org_kde_powerdevil), but reproduces standalone with plain ddcutil detect / ddcutil environment
  • GPUs: AMD Radeon 780M (iGPU, amdgpu, always present as card1) + NVIDIA GeForce RTX 4060 Laptop GPU (dGPU, dynamically switched, normally card0)
  • GPU switcher: cardwire (rust daemon, eBPF-LSM-based GPU blocker), currently in Integrated mode → dGPU blocked
  • Secure Boot: enabled → cardwire running in its "weakened" fallback blocking mode (see root cause below)

Reproduction

  1. Have a hybrid-graphics laptop with Secure Boot enabled, running cardwire in "Integrated" mode (dGPU blocked via its Secure-Boot-lockdown fallback path, see cardwire PR #266). Other tools/configs that leave a GPU's PCI device listed-but-unreadable in sysfs (rather than cleanly unbound/removed) would likely trigger the same state.
  2. While the dGPU is blocked, /sys/class/drm/ retains entries for it that don't resolve (stat → ENOENT), e.g.: 
    $ ls -la /sys/class/drm/
l??????????  ? ?    ?       ?            ? card0
l??????????  ? ?    ?       ?            ? card0-eDP-2
l??????????  ? ?    ?       ?            ? card0-HDMI-A-2
l??????????  ? ?    ?       ?            ? renderD129
lrwxrwxrwx.  1 root root 0 ... card1 -> ../../devices/pci.../drm/card1
lrwxrwxrwx.  1 root root 0 ... card1-DP-1 -> ...
... (card1-* entries resolve fine)
  3. Run ddcutil detect (or ddcutil detect --verbose, or ddcutil environment, or just start powerdevil).
  4. Segfault, every time.

Backtrace (gdb on coredump, no debuginfo installed — function names only)

#0  0x00005632967b5001 in sysfs_find_adapter ()
#1  0x00005632967b51d7 in find_adapter_and_get_driver ()
#2  0x00005632967b5c7c in check_connector_reliability ()
#3  0x00005632967f32ad in dir_foreach ()
#4  0x00005632967b4a3a in check_sysfs_reliability ()
#5  0x00005632967b4c09 in is_sysfs_reliable_for_driver ()
#6  0x00005632967af9f7 in i2c_check_bus ()
#7  0x00005632967b034a in i2c_non_async_scan ()
#8  0x00005632967b0620 in i2c_detect_buses0 ()
#9  0x00005632967b084d in i2c_detect_buses ()
#10 0x000056329678dac3 in ddc_detect_all_displays ()
#11 0x000056329678e5dc in ddc_ensure_displays_detected ()
#12 0x000056329676c788 in main ()

The same crash occurs inside libddcutil when called from powerdevil, with an equivalent stack through ddci_init → i2c_detect_buses → ... → sysfs_find_adapter (see attached powerdevil journal/coredump).

Full bt full and coredumpctl info output attached.

Impact on powerdevil

Because libddcutil init happens during powerdevil's startup (ScreenBrightnessController::detectDisplays → DDCutilDetector::detect → DDCutilPrivateSingleton::instance → ddci_init), and the dGPU stays off for the whole session under cardwire's "Integrated" mode, plasma-powerdevil.service crash-loops on every login (5 restarts, then Start request repeated too quickly, service ends up failed). This effectively disables Plasma's power-management daemon (screen brightness policies, idle timeouts, suspend-on-lid, etc.) for the whole session, until manually reset with systemctl --user reset-failed plasma-powerdevil.service (which doesn't help until the dGPU sysfs entries are gone/valid again).

Root cause hypothesis

check_connector_reliability() (called via dir_foreach() over what looks like /sys/class/drm/*) calls find_adapter_and_get_driver() → sysfs_find_adapter() for every DRM connector entry, including ones whose backing device has disappeared (dangling symlink / ENOENT on stat). The code apparently doesn't handle a connector directory that fails to resolve (e.g. readlink/realpath/opendir returning NULL or an error) and dereferences a NULL/invalid pointer.

This is very likely the same general class of bug as #408 ("Segfault in scan_sys_drm_connectors... /sys is in an unexpected state after waking from sleep") — i.e. ddcutil's sysfs scanning code assumes /sys/class/drm/* entries are always fully resolvable, which does not hold when a GPU is unbound/removed (suspend/resume in #408's case, dynamic GPU-switching in this case). Filing separately since the trigger and specific function (sysfs_find_adapter vs scan_sys_drm_connectors) differ, but the maintainer may want to treat them as the same underlying hardening issue.

Suggested fix

Harden sysfs_find_adapter()/find_adapter_and_get_driver()/check_connector_reliability() to tolerate a DRM connector directory entry that no longer resolves (stale/dangling), by checking return values before dereferencing rather than assuming /sys/class/drm/* is a stable snapshot. This matters for any hybrid-graphics setup where a GPU-switcher tool (supergfxctl, cardwire, etc.) unbinds/powers off a GPU at runtime.

Workaround

Correction after filing: the "Control hardware brightness with DDC/CI" checkbox in Plasma's Display settings does not prevent this crash — ScreenBrightnessController constructs a DDCutilDetector and calls detect() on it unconditionally on every detectDisplays() run (daemon/controllers/screenbrightnesscontroller.cpp), with no KConfig check gating it. That per-display setting only affects whether an already-detected DDC/CI display gets used, not whether powerdevil scans for one in the first place.

The actual working workaround: powerdevil's DDCutilDetector constructor checks POWERDEVIL_NO_DDCUTIL (daemon/controllers/ddcutildetector.cpp):

m_noDdcutil = qEnvironmentVariableIntValue("POWERDEVIL_NO_DDCUTIL") > 0;
if (m_noDdcutil) {
    return; // skips ddca_init2() entirely
}

Setting POWERDEVIL_NO_DDCUTIL=1 for the plasma-powerdevil.service process (e.g. via a systemd user-service drop-in) skips ddca_init2()/all libddcutil calls entirely, avoiding the crash. Confirmed this fixes the crash-loop on my system (NRestarts=0, stays active (running)). Cost: DDC/CI brightness control is disabled for all external monitors for the whole session (not just ones on the blocked dGPU) — internal laptop-screen backlight and KWin-based brightness control are unaffected, they use separate detectors.

Attachments

  • ddcutil-coredump-info.txt — coredumpctl info for the ddcutil detect crash
  • ddcutil-gdb-bt.txt — coredumpctl gdb full backtrace (bt full)
  • (available on request) unstripped /usr/bin/ddcutil + libddcutil.so.5 with debuginfo, or a debuginfo-symbolized backtrace, if useful — can provide with ddcutil-debuginfo/libddcutil-debuginfo installed.

Activity

  1. plastininikolay commented on Sep 24, 2026

    @plastininikolay
    plastininikolay
    on Sep 24, 2026
    Author

    ddcutil-coredump-info.txt

               PID: 7809 (ddcutil)
           UID: 1000 (nikolay)
           GID: 1000 (nikolay)
        Signal: 11 (SEGV)
     Timestamp: Thu 2026-09-24 22:33:49 +08 (10s ago)
  Command Line: ddcutil detect --verbose
    Executable: /usr/bin/ddcutil
 Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-4677.scope/tab(4762).scope
          Unit: user@1000.service
     User Unit: app-org.kde.konsole-4677.scope
         Slice: user-1000.slice
     Owner UID: 1000 (nikolay)
       Boot ID: 360de32312b347b4a90da185c88bc4b8
    Machine ID: 55048cabbfee4de2b78a5b683d14138c
      Hostname: asusrog
       Storage: /var/lib/systemd/coredump/core.ddcutil.1000.360de32312b347b4a90da185c88bc4b8.7809.1790260429000000.zst (present)
  Size on Disk: 145.3K
       Package: ddcutil/2.2.1-3.fc44
      build-id: 003305a55991501df52141927636fcc3c5cecb66
       Message: Process 7809 (ddcutil) of user 1000 dumped core.
                
                Module libXau.so.6 from rpm libXau-1.0.12-4.fc44.x86_64
                Module libpcre2-8.so.0 from rpm pcre2-10.47-1.fc44.1.x86_64
                Module libXrender.so.1 from rpm libXrender-0.9.12-4.fc44.x86_64
                Module libxcb.so.1 from rpm libxcb-1.17.0-7.fc44.x86_64
                Module libdrm.so.2 from rpm libdrm-2.4.134-1.fc44.x86_64
                Module libudev.so.1 from rpm systemd-259.9-1.fc44.x86_64
                Module libglib-2.0.so.0 from rpm glib2-2.88.3-1.fc44.x86_64
                Module libjansson.so.4 from rpm jansson-2.14-4.fc44.x86_64
                Module libXrandr.so.2 from rpm libXrandr-1.5.4-7.fc44.x86_64
                Module libXext.so.6 from rpm libXext-1.3.6-5.fc44.x86_64
                Module libX11.so.6 from rpm libX11-1.8.13-1.fc44.x86_64
                Module ddcutil from rpm ddcutil-2.2.1-3.fc44.x86_64
                Stack trace of thread 7809:
                #0  0x000055b3f4501001 sysfs_find_adapter (ddcutil + 0x53001)
                #1  0x000055b3f45011d7 find_adapter_and_get_driver (ddcutil + 0x531d7)
                #2  0x000055b3f4501c7c check_connector_reliability (ddcutil + 0x53c7c)
                #3  0x000055b3f453f2ad dir_foreach (ddcutil + 0x912ad)
                #4  0x000055b3f4500a3a check_sysfs_reliability (ddcutil + 0x52a3a)
                #5  0x000055b3f4500c09 is_sysfs_reliable_for_driver (ddcutil + 0x52c09)
                #6  0x000055b3f44fb9f7 i2c_check_bus (ddcutil + 0x4d9f7)
                #7  0x000055b3f44fc34a i2c_non_async_scan (ddcutil + 0x4e34a)
                #8  0x000055b3f44fc620 i2c_detect_buses0 (ddcutil + 0x4e620)
                #9  0x000055b3f44fc84d i2c_detect_buses (ddcutil + 0x4e84d)
                #10 0x000055b3f44d9ac3 ddc_detect_all_displays (ddcutil + 0x2bac3)
                #11 0x000055b3f44da5dc ddc_ensure_displays_detected (ddcutil + 0x2c5dc)
                #12 0x000055b3f44b8788 main (ddcutil + 0xa788)
                #13 0x00007f6ed532d681 __libc_start_call_main (libc.so.6 + 0x3681)
                #14 0x00007f6ed532d798 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x3798)
                #15 0x000055b3f44b8aa5 _start (ddcutil + 0xaaa5)
                ELF object binary architecture: AMD x86-64

    ddcutil-gdb-bt.txt

               PID: 7809 (ddcutil)
           UID: 1000 (nikolay)
           GID: 1000 (nikolay)
        Signal: 11 (SEGV)
     Timestamp: Thu 2026-09-24 22:33:49 +08 (10s ago)
  Command Line: ddcutil detect --verbose
    Executable: /usr/bin/ddcutil
 Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-4677.scope/tab(4762).scope
          Unit: user@1000.service
     User Unit: app-org.kde.konsole-4677.scope
         Slice: user-1000.slice
     Owner UID: 1000 (nikolay)
       Boot ID: 360de32312b347b4a90da185c88bc4b8
    Machine ID: 55048cabbfee4de2b78a5b683d14138c
      Hostname: asusrog
       Storage: /var/lib/systemd/coredump/core.ddcutil.1000.360de32312b347b4a90da185c88bc4b8.7809.1790260429000000.zst (present)
  Size on Disk: 145.3K
       Package: ddcutil/2.2.1-3.fc44
      build-id: 003305a55991501df52141927636fcc3c5cecb66
       Message: Process 7809 (ddcutil) of user 1000 dumped core.
                
                Module libXau.so.6 from rpm libXau-1.0.12-4.fc44.x86_64
                Module libpcre2-8.so.0 from rpm pcre2-10.47-1.fc44.1.x86_64
                Module libXrender.so.1 from rpm libXrender-0.9.12-4.fc44.x86_64
                Module libxcb.so.1 from rpm libxcb-1.17.0-7.fc44.x86_64
                Module libdrm.so.2 from rpm libdrm-2.4.134-1.fc44.x86_64
                Module libudev.so.1 from rpm systemd-259.9-1.fc44.x86_64
                Module libglib-2.0.so.0 from rpm glib2-2.88.3-1.fc44.x86_64
                Module libjansson.so.4 from rpm jansson-2.14-4.fc44.x86_64
                Module libXrandr.so.2 from rpm libXrandr-1.5.4-7.fc44.x86_64
                Module libXext.so.6 from rpm libXext-1.3.6-5.fc44.x86_64
                Module libX11.so.6 from rpm libX11-1.8.13-1.fc44.x86_64
                Module ddcutil from rpm ddcutil-2.2.1-3.fc44.x86_64
                Stack trace of thread 7809:
                #0  0x000055b3f4501001 sysfs_find_adapter (ddcutil + 0x53001)
                #1  0x000055b3f45011d7 find_adapter_and_get_driver (ddcutil + 0x531d7)
                #2  0x000055b3f4501c7c check_connector_reliability (ddcutil + 0x53c7c)
                #3  0x000055b3f453f2ad dir_foreach (ddcutil + 0x912ad)
                #4  0x000055b3f4500a3a check_sysfs_reliability (ddcutil + 0x52a3a)
                #5  0x000055b3f4500c09 is_sysfs_reliable_for_driver (ddcutil + 0x52c09)
                #6  0x000055b3f44fb9f7 i2c_check_bus (ddcutil + 0x4d9f7)
                #7  0x000055b3f44fc34a i2c_non_async_scan (ddcutil + 0x4e34a)
                #8  0x000055b3f44fc620 i2c_detect_buses0 (ddcutil + 0x4e620)
                #9  0x000055b3f44fc84d i2c_detect_buses (ddcutil + 0x4e84d)
                #10 0x000055b3f44d9ac3 ddc_detect_all_displays (ddcutil + 0x2bac3)
                #11 0x000055b3f44da5dc ddc_ensure_displays_detected (ddcutil + 0x2c5dc)
                #12 0x000055b3f44b8788 main (ddcutil + 0xa788)
                #13 0x00007f6ed532d681 __libc_start_call_main (libc.so.6 + 0x3681)
                #14 0x00007f6ed532d798 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x3798)
                #15 0x000055b3f44b8aa5 _start (ddcutil + 0xaaa5)
                ELF object binary architecture: AMD x86-64

GNU gdb (Fedora Linux) 17.2-2.fc44
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/ddcutil...

This GDB supports auto-downloading debuginfo from the following URLs:
  <ima:enforcing>
  <https://debuginfod.fedoraproject.org/>
  <ima:ignore>
Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
Reading symbols from .gnu_debugdata for /usr/bin/ddcutil...
(No debugging symbols found in .gnu_debugdata for /usr/bin/ddcutil)
[New LWP 7809]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/bin/ddcutil detect --verbose'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055b3f4501001 in sysfs_find_adapter ()
Missing rpms, try: dnf --enablerepo='*debug*' install ddcutil-debuginfo-2.2.1-3.fc44.x86_64 libX11-debuginfo-1.8.13-1.fc44.x86_64 libXext-debuginfo-1.3.6-5.fc44.x86_64 libXrandr-debuginfo-1.5.4-7.fc44.x86_64 jansson-debuginfo-2.14-4.fc44.x86_64 glib2-debuginfo-2.88.3-1.fc44.x86_64 systemd-libs-debuginfo-259.9-1.fc44.x86_64 libdrm-debuginfo-2.4.134-1.fc44.x86_64 libgcc-debuginfo-16.2.1-2.fc44.x86_64 glibc-debuginfo-2.43-8.fc44.x86_64 libxcb-debuginfo-1.17.0-7.fc44.x86_64 libXrender-debuginfo-0.9.12-4.fc44.x86_64 pcre2-debuginfo-10.47-1.fc44.1.x86_64 libXau-debuginfo-1.0.12-4.fc44.x86_64
(gdb) #0  0x000055b3f4501001 in sysfs_find_adapter ()
No symbol table info available.
#1  0x000055b3f45011d7 in find_adapter_and_get_driver ()
No symbol table info available.
#2  0x000055b3f4501c7c in check_connector_reliability ()
No symbol table info available.
#3  0x000055b3f453f2ad in dir_foreach ()
No symbol table info available.
#4  0x000055b3f4500a3a in check_sysfs_reliability ()
No symbol table info available.
#5  0x000055b3f4500c09 in is_sysfs_reliable_for_driver ()
No symbol table info available.
#6  0x000055b3f44fb9f7 in i2c_check_bus ()
No symbol table info available.
#7  0x000055b3f44fc34a in i2c_non_async_scan ()
No symbol table info available.
#8  0x000055b3f44fc620 in i2c_detect_buses0 ()
No symbol table info available.
#9  0x000055b3f44fc84d in i2c_detect_buses ()
No symbol table info available.
#10 0x000055b3f44d9ac3 in ddc_detect_all_displays ()
No symbol table info available.
#11 0x000055b3f44da5dc in ddc_ensure_displays_detected ()
No symbol table info available.
#12 0x000055b3f44b8788 in main ()
No symbol table info available.
(gdb) ```

  2. rockowitz commented on Sep 24, 2026

    @rockowitz
    rockowitz
    on Sep 24, 2026
    Owner

    This should be straightforward to fix, though I wouldn't be surprised to see other problems surface once this one is fixed.

    In the meantime, I;m curious to know the effect of using utility option --f21, which forces sysfs to be regarded as unreliable and skips the problematic code. (This utility option was defined to aid in debugging.) For the option to be recognized by libddcutil it needs to be put in your ddcutil configuration file:

    [global]
options: --f21

    Also of note is option --disable-api as alternative way to disable PowerDevil's use of libddcutil.

  3. plastininikolay commented on Sep 24, 2026

    @plastininikolay
    plastininikolay
    on Sep 24, 2026
    Author

    Thanks! --f21 doesn't avoid the crash here. Tested in the same state (Integrated mode, dGPU blocked):

    • ddcutil detect --f21 → SIGSEGV
    • options: --f21 under [global] in ~/.config/ddcutil/ddcutilrc, then ddcutil detect → SIGSEGV

    Same backtrace both times:
    sysfs_find_adapter ← find_adapter_and_get_driver ← check_connector_reliability ← dir_foreach ← check_sysfs_reliability ← is_sysfs_reliable_for_driver ← i2c_check_bus

    So check_sysfs_reliability() still runs with --f21. I'm happy to test a fix.

    (Tested with the help of Claude Code; I ran the commands on my laptop.)

  4. rockowitz commented on Sep 24, 2026

    @rockowitz
    rockowitz
    on Sep 24, 2026
    Owner

    Thanks for checking. Looks like I have 2 issues to deal with.

  5. rockowitz commented on Sep 26, 2026

    @rockowitz
    rockowitz
    on Sep 26, 2026
    Owner

    The segfault you reported was already fixed in commit `ebfacc401, released in ddcutil 3.0.0. You're on 2.2.1, which is quite old. Iif you build and install ddcutil 3.0.2 (which replaced 3.0.0), or development branch 3.0.3-dev you should not encounter the segfault.

    Beyond that, how to handle the problem well, beyond not crashing, is unclear. Several functions that walk /sys/class/drm still take a listed-but-unresolvable entry for a real connector. The one with a visible consequence is check_connector_reliability(): the driver lookup for a dangling entry returns NULL, which is indistinguishable from an unrecognized driver, so ddcutil concludes an unknown driver is present and reports sysfs as unreliable for the whole system — which would disable the sysfs-based optimizations for your working amdgpu card on account of the blocked NVIDIA one. There are three more of the same shape, one of which also terminates its scan early.

    The basic problem is that libddcutil does not handle the situation where a connector can move back and forth between resolvable and unresolvable, which entails data structures that were expected to be persistent and unchanged. As I worked on this each, solution encountered edge cases whose solution encountered further edge cases, convoluting the code. And, tell me if you disagree, I think your use case is rare and doesn't justify extensive changes to the code base. But I'll continue to look at the the problem.

  6. rockowitz
    added
    bug
    enhancement
    Fixed
    on Sep 28, 2026

  7. plastininikolay commented on Sep 30, 2026

    @plastininikolay
    plastininikolay
    on Sep 30, 2026
    Author

    Thanks, that explains it: Fedora 44 still ships 2.2.1 (3.0.2 is only in Fedora 46 so far), and I filed this against it.

    I rebuilt the Fedora 46 ddcutil-3.0.2 package for Fedora 44 in mock. In the mode where the NVIDIA card is active, both 2.2.1 and 3.0.2 detect the external monitor fine. Reproducing the crash needs the card blocked by Cardwire, which on this laptop requires switching the MUX to hybrid and rebooting, so I'll do that and report back with a full ddcutil environment log from 3.0.2 in that state.

    Agreed that a connector flipping between resolvable and unresolvable is a rare case. From my side "no crash, and the amdgpu card keeps working" is good enough; if the log from the blocked state is useful for looking at check_connector_reliability(), I'll attach it.

  8. plastininikolay commented on Sep 30, 2026

    @plastininikolay
    plastininikolay
    on Sep 30, 2026
    Author

    Tested with the NVIDIA card blocked (MUX in hybrid mode, on battery, Cardwire in Integrated mode, Secure Boot / lockdown=integrity, kernel 7.2.7, Fedora 44):

    ddcutil detect
    2.2.1 (Fedora 44 package) SIGSEGV, exit code 139 (coredump in sysfs_find_adapter as reported)
    3.0.2 (Fedora 46 package rebuilt for Fedora 44) exit code 0, no crash

    So the crash is indeed gone in 3.0.x, thanks.

    What 3.0.2 prints in this state: the blocked card's entries are still listed in /sys/class/drm (card0, card0-eDP-2, card0-HDMI-A-2, renderD129) but cannot be resolved, so detect prints nine identical pairs of

    Error opening "/sys/class/drm/card0-HDMI-A-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-eDP-2/edid", No such file or directory

    then Unable to open directory /sys/devices/pci0000:00/0000:00:01.1: No such file or directory, and then reports the amdgpu laptop panel (card1-eDP-1) normally. For my use case that is fine: no crash, and the working card is handled. The repeated messages are only cosmetic.

    I'll ask the Fedora maintainer whether 3.0.x can go to Fedora 44/45, since powerdevil there crashes on login in this setup with 2.2.1.

    ddcutil 3.0.2 environment, NVIDIA card blocked 
    Error opening "/sys/class/drm/card0-HDMI-A-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-eDP-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-HDMI-A-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-eDP-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-HDMI-A-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-eDP-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-HDMI-A-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-eDP-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-HDMI-A-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-eDP-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-HDMI-A-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-eDP-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-HDMI-A-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-eDP-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-HDMI-A-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-eDP-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-HDMI-A-2/edid", No such file or directory
Error opening "/sys/class/drm/card0-eDP-2/edid", No such file or directory
Error opening /sys/bus/pci/devices/0000:01:00.0/class: No such file or directory
Error opening /sys/bus/pci/devices/0000:00:01.1/class: No such file or directory
Error opening /sys/bus/pci/devices/0000:01:00.1/class: No such file or directory
      Unable to open directory /sys/devices/pci0000:00/0000:00:01.1: No such file or directory
The following tests probe the runtime environment using multiple overlapping methods.
*** Basic System Information ***

ddcutil version: 3.0.2

/proc/version:
   Linux version 7.2.7-200.fc44.x86_64 (mockbuild@4bc3738664d84c798c5efe0695a77dbf) (gcc (GCC) 16.2.1 20260819 (Red Hat 16.2.1-2), GNU ld version 2.46.1-1.fc44) #1 SMP PREEMPT_DYNAMIC Mon Sep 21 18:25:57 UTC 2026

Architecture:     x86_64
Distributor id:   Fedora
Release:          44
Found a known architecture

/proc/cmdline:
   BOOT_IMAGE=(hd0,gpt2)/vmlinuz-7.2.7-200.fc44.x86_64 root=UUID=<redacted> ro rootflags=subvol=root rhgb quiet rd.driver.blacklist=nouveau,nova_core modprobe.blacklist=nouveau,nova_core

*** Primary Check 1: Identify video card and driver ***

Obtaining card and driver information from /sys...
Unexpected for /sys/bus/pci/devices/0000:01:00.0: class not found
Unexpected for /sys/bus/pci/devices/0000:00:01.1: class not found
Primary video controller at PCI address 0000:69:00.0 (boot_vga flag is set)
   Device class:        x030000    VGA compatible controller
   Vendor:              x1002      Advanced Micro Devices, Inc. [AMD/ATI]
   Device:              x15bf      Phoenix1
   Subvendor/Subdevice: 1043/1533  ASUSTeK Computer Inc.
   Driver name:         amdgpu
   Driver version:      Unable to determine
   I2C device:          i2c-3      name: AMDGPU DM i2c hw bus 0
   I2C device:          i2c-10     name: AMDGPU DM i2c hw bus 7
   I2C device:          i2c-8      name: AMDGPU DM i2c hw bus 5
   I2C device:          i2c-6      name: AMDGPU DM i2c hw bus 3
   I2C device:          i2c-4      name: AMDGPU DM i2c hw bus 1
   I2C device:          i2c-11     name: AMDGPU DM i2c hw bus 8
   I2C device:          i2c-9      name: AMDGPU DM i2c hw bus 6
   I2C device:          i2c-7      name: AMDGPU DM i2c hw bus 4
   I2C device:          i2c-5      name: AMDGPU DM i2c hw bus 2
Unexpected for /sys/bus/pci/devices/0000:01:00.1: class not found

*** Primary Check 2: Check that /dev/i2c-* exist and writable ***

Current user: nikolay (1000)

Checking /dev/i2c-* devices...

Devices /dev/i2c-* must exist and the logged on user must have read/write permission for those devices (or at least those devices associated 
with monitors).

Typically, this access is enabled by:
  - setting the group for /dev/i2c-* to i2c
  - setting group RW permissions for /dev/i2c-*
  - making the current user a member of group i2c

Alternatively, this can be enabled by just giving everyone RW permission
The following tests probe for these conditions.

Checking for /dev/i2c-* devices...
   crw-rw----+ 1 root root 89,  0 сен 30 15:06 /dev/i2c-0
   crw-rw----+ 1 root root 89,  1 сен 30 15:06 /dev/i2c-1
   crw-rw----+ 1 root root 89, 10 сен 30 15:06 /dev/i2c-10
   crw-rw----+ 1 root root 89, 11 сен 30 15:06 /dev/i2c-11
   crw-rw----+ 1 root root 89, 12 сен 30 15:06 /dev/i2c-12
   crw-rw----+ 1 root root 89, 13 сен 30 15:06 /dev/i2c-13
   crw-rw----+ 1 root root 89, 14 сен 30 15:06 /dev/i2c-14
   crw-rw----+ 1 root root 89, 15 сен 30 15:06 /dev/i2c-15
   crw-rw----+ 1 root root 89, 16 сен 30 15:06 /dev/i2c-16
   crw-rw----+ 1 root root 89, 17 сен 30 15:06 /dev/i2c-17
   crw-rw----+ 1 root root 89, 18 сен 30 15:06 /dev/i2c-18
   crw-rw----+ 1 root root 89, 19 сен 30 15:06 /dev/i2c-19
   crw-rw----+ 1 root root 89,  2 сен 30 15:06 /dev/i2c-2
   crw-rw----+ 1 root root 89, 20 сен 30 15:06 /dev/i2c-20
   crw-rw----+ 1 root root 89, 21 сен 30 15:06 /dev/i2c-21
   crw-rw----+ 1 root root 89, 22 сен 30 15:06 /dev/i2c-22
   crw-------. 1 root root 89, 23 сен 30 15:06 /dev/i2c-23
   crw-------. 1 root root 89, 24 сен 30 15:06 /dev/i2c-24
   crw-------. 1 root root 89, 25 сен 30 15:06 /dev/i2c-25
   crw-rw----+ 1 root root 89,  3 сен 30 15:06 /dev/i2c-3
   crw-rw----+ 1 root root 89,  4 сен 30 15:06 /dev/i2c-4
   crw-rw----+ 1 root root 89,  5 сен 30 15:06 /dev/i2c-5
   crw-rw----+ 1 root root 89,  6 сен 30 15:06 /dev/i2c-6
   crw-rw----+ 1 root root 89,  7 сен 30 15:06 /dev/i2c-7
   crw-rw----+ 1 root root 89,  8 сен 30 15:06 /dev/i2c-8
   crw-rw----+ 1 root root 89,  9 сен 30 15:06 /dev/i2c-9
Device /dev/i2c-23 is not readable and writable.  Error = EACCES(13): Permission denied
Device /dev/i2c-24 is not readable and writable.  Error = EACCES(13): Permission denied
Device /dev/i2c-25 is not readable and writable.  Error = EACCES(13): Permission denied

WARNING: Current user (nikolay) does not have RW access to all /dev/i2c-* devices.

Checking for group i2c...
   Group i2c does not exist

Looking for udev rules files that reference i2c:
   Checking rules directory /lib/udev/rules.d:
      /lib/udev/rules.d/60-autosuspend.rules:SUBSYSTEM=="i2c", ATTR{name}=="cyapa", \
      /lib/udev/rules.d/60-ddcutil-i2c.rules:SUBSYSTEM=="i2c-dev", KERNEL=="i2c-[0-9]*", ATTRS{class}=="0x030000", TAG+="uaccess"
      /lib/udev/rules.d/60_flashrom.rules:# http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
      /lib/udev/rules.d/60-input-id.rules:        IMPORT{builtin}="hwdb 'id-input:i2c:v$attr{id/vendor}p$attr{id/product}:name:$attr{name}:'", \
      /lib/udev/rules.d/60-openrgb.rules:KERNEL=="i2c-[0-99]*", TAG+="uaccess"
      /lib/udev/rules.d/60-persistent-input.rules:# allow empty class for platform, usb and i2c devices; platform supports only a single interface that way
      /lib/udev/rules.d/60-persistent-input.rules:SUBSYSTEMS=="usb|platform|i2c", KERNEL=="event*", ENV{.INPUT_CLASS}=="", ENV{ID_PATH}=="?*", \
      /lib/udev/rules.d/60-persistent-input.rules:SUBSYSTEMS=="usb|platform|i2c", KERNEL=="event*", ENV{.INPUT_CLASS}=="", ENV{ID_PATH_WITH_USB_REVISION}=="?*", \
      /lib/udev/rules.d/60-sensor.rules:SUBSYSTEM=="iio", KERNEL=="iio*", SUBSYSTEMS=="usb|i2c|platform", ATTR{label}!="", \
      /lib/udev/rules.d/60-sensor.rules:SUBSYSTEM=="iio", KERNEL=="iio*", SUBSYSTEMS=="usb|i2c|platform", \
   Checking rules directory /run/udev/rules.d:
      grep: /run/udev/rules.d/*rules: Нет такого файла или каталога
   Checking rules directory /etc/udev/rules.d:

*** Primary Check 3: Check that module i2c_dev is loaded ***

Checking for driver i2c_dev...
   sysfs reports module i2c_dev is loaded.
   Module i2c_dev is NOT built into the kernel
   Loadable i2c-dev module found
   Module i2c_dev is loaded

*** Primary Check 4: Driver specific checks ***

Performing driver specific checks...
No driver specific checks apply.

*** Additional probes ***

Examining /sys/bus/i2c/devices...
   /sys/bus/i2c/devices/i2c-ASUE120A:00/name: ASUE120A:00
   /sys/bus/i2c/devices/i2c-CSC3551:00-cs35l41-hda.0/name: cs35l41-hda
   /sys/bus/i2c/devices/i2c-CSC3551:00-cs35l41-hda.1/name: cs35l41-hda
   /sys/bus/i2c/devices/i2c-ELAN9008:00/name: ELAN9008:00
   /sys/bus/i2c/devices/i2c-PS883008:00/name: PS883008:00
   /sys/bus/i2c/devices/i2c-PS88300A:00/name: PS88300A:00
   /sys/bus/i2c/devices/i2c-PS88300F:00/name: PS88300F:00
   /sys/bus/i2c/devices/i2c-PS883011:00/name: PS883011:00
   /sys/bus/i2c/devices/i2c-PS883018:00/name: PS883018:00
   /sys/bus/i2c/devices/i2c-PS88301A:00/name: PS88301A:00
   /sys/bus/i2c/devices/i2c-PS88301F:00/name: PS88301F:00
   /sys/bus/i2c/devices/i2c-PS883021:00/name: PS883021:00
   /sys/bus/i2c/devices/i2c-0/name:   Synopsys DesignWare I2C adapter
   /sys/bus/i2c/devices/i2c-1/name:   Synopsys DesignWare I2C adapter
   /sys/bus/i2c/devices/i2c-2/name:   Synopsys DesignWare I2C adapter
   /sys/bus/i2c/devices/i2c-3/name:   AMDGPU DM i2c hw bus 0
   /sys/bus/i2c/devices/i2c-4/name:   AMDGPU DM i2c hw bus 1
   /sys/bus/i2c/devices/i2c-5/name:   AMDGPU DM i2c hw bus 2
   /sys/bus/i2c/devices/i2c-6/name:   AMDGPU DM i2c hw bus 3
   /sys/bus/i2c/devices/i2c-7/name:   AMDGPU DM i2c hw bus 4
   /sys/bus/i2c/devices/i2c-8/name:   AMDGPU DM i2c hw bus 5
   /sys/bus/i2c/devices/i2c-9/name:   AMDGPU DM i2c hw bus 6
   /sys/bus/i2c/devices/i2c-10/name:  AMDGPU DM i2c hw bus 7
   /sys/bus/i2c/devices/i2c-11/name:  AMDGPU DM i2c hw bus 8
   /sys/bus/i2c/devices/i2c-12/name:  AMError opening /sys/bus/i2c/devices/i2c-23/name: No such file or directory
Error opening /sys/bus/i2c/devices/i2c-24/name: No such file or directory
Error opening /sys/bus/i2c/devices/i2c-25/name: No such file or directory
DGPU DM aux hw bus 0
   /sys/bus/i2c/devices/i2c-13/name:  AMDGPU DM aux hw bus 2
   /sys/bus/i2c/devices/i2c-14/name:  AMDGPU DM aux hw bus 3
   /sys/bus/i2c/devices/i2c-15/name:  AMDGPU DM aux hw bus 4
   /sys/bus/i2c/devices/i2c-16/name:  AMDGPU DM aux hw bus 5
   /sys/bus/i2c/devices/i2c-17/name:  AMDGPU DM aux hw bus 6
   /sys/bus/i2c/devices/i2c-18/name:  AMDGPU DM aux hw bus 7
   /sys/bus/i2c/devices/i2c-19/name:  AMDGPU DM aux hw bus 8
   /sys/bus/i2c/devices/i2c-20/name:  SMBus PIIX4 adapter port 0 at 0b00
   /sys/bus/i2c/devices/i2c-21/name:  SMBus PIIX4 adapter port 2 at 0b00
   /sys/bus/i2c/devices/i2c-22/name:  SMBus PIIX4 adapter port 1 at 0b20
   /sys/bus/i2c/devices/i2c-23/name:  (null)
   /sys/bus/i2c/devices/i2c-24/name:  (null)
   /sys/bus/i2c/devices/i2c-25/name:  (null)

Env_Accumulator:
   architecture:                  x86_64
   distributor_id                 Fedora
   Drivers detected:              amdgpu
   /dev/i2c device numbers:       0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
   sysfs_i2c_devices_exist:       true
   /sys/bus/i2c device numbers:   0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
   dev_i2c_devices_required:      true
   module_i2c_dev_needed:         true
   module_i2c_dev_builtin:        false
   loadable_i2c_dev_exists:       true
   i2c_dev_loaded_or_builtin:     true
   group_i2c_checked:             true
   group_i2c_exists:              false
   dev_i2c_common_group_name:     root
   all_dev_i2c_has_group_i2c:     false
   any_dev_i2c_has_group_i2c:     false
   all_dev_i2c_is_group_rw:       true
   any_dev_i2c_is_group_rw:       false
   cur_uname:                     nikolay
   cur_uid:                       1000
   cur_user_in_group_i2c:         false
   cur_user_any_devi2c_rw:        true
   cur_user_all_devi2c_rw:        false

Configuration suggestions:
   Issue:
      Current user has RW access to some but not all /dev/i2c-N devices.
      If there is RW access to at least the /dev/i2c-N devices for connected monitors,
      this is not a problem.
      Remaining suggestions assume RW access is still to be established.
      
   Issue:
      Group i2c does not exist.
   Suggestion:
      Create group i2c. To create group i2c, use command:
         sudo groupadd --system i2c
      Assign /dev/i2c-N devices to group i2c by adding a rule to /etc/udev/rules.d
      Add the current user to group i2c:
         sudo usermod -G i2c -a <username>
      After this, you will have to logout and login again.
      The changes to the user's group list are not read until a new login.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Fixedbugenhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions