Repository navigation
Hard kernel freeze triggered by "Double connect" warning on USB reconnect (Fedora 43, kernel 6.18.x) #557
Description
System Information
- OS: Fedora 43
- Kernel: 6.18.12-200.fc43.x86_64
- DisplayLink package: displaylink-1.14.14-1.github_evdi.x86_64
- EVDI module: loaded from displaylink package
- GPU (primary): Intel Iris Plus Graphics G7 (i915 driver)
- GPU (secondary): NVIDIA GeForce MX330 (nvidia-drm driver)
- DisplayLink device: HP Z23n monitor via USB (1920x1080@60Hz)
Description
After a USB reconnect event (e.g. hub reconnect or system resume), the EVDI driver
logs a "Double connect" warning. Within 5–20 minutes of this event, the system
experiences a complete hard freeze requiring a forced power cycle.
The kernel journal is truncated at the point of freeze (no panic output), and
wtmp records the session as crash rather than clean shutdown.
Kernel log at time of event
evdi: [W] evdi_painter_connect:896 (card2) Double connect - replacing 0000000003e0ecdd with 0000000003e0ecdd
This warning appeared in every single crash observed (3 occurrences over 2 days),
always preceding the freeze by a few minutes.
Reproducing
- Connect a DisplayLink monitor via USB
- Disconnect and reconnect the USB (or trigger a suspend/resume)
- Observe
Double connectwarning indmesg/journalctl - System freezes completely within ~5–20 minutes, no recovery possible
Additional context
- With
initial_device_count=4(default), the system had 4 EVDI virtual devices
(card2–card5) for a single physical DisplayLink monitor, which may increase
the probability of triggering the race condition - Reducing to
initial_device_count=1via/etc/modprobe.d/evdi.confappears to
reduce frequency but does not eliminate the warning - No kernel panic dump is generated — the freeze is a hard lockup with no output
- Prior sessions on kernel 6.18.9 showed identical behavior
Logs
Previous freeze (kernel 6.18.9, boot -1):
Feb 21 11:07:31 kernel: evdi: [W] evdi_painter_connect:896 (card3) Double connect - replacing ...
[system froze ~20 minutes later, journal truncated]
Current session (kernel 6.18.12):
Feb 21 21:59:58 kernel: evdi: [W] evdi_painter_connect:896 (card2) Double connect - replacing 0000000003e0ecdd with 0000000003e0ecdd
[system froze ~28 minutes later, journal truncated]
Also observed at boot:
gnome-shell: Failed to initialize accelerated iGPU/dGPU framebuffer sharing: Not hardware accelerated
gnome-shell: Failed to determine deadline: drmWaitVBlank failed: Unknown error -1
Workarounds attempted
- Reduced
initial_device_countfrom 4 to 1 — reduces device proliferation but
does not fix the double connect race - Added kernel watchdog params (
nmi_watchdog=1 softlockup_panic=1 hardlockup_panic=1)
to force reboot on lockup instead of freezing indefinitely
Expected behavior
The evdi_painter_connect function should handle a double connect gracefully
without leaving the driver in a state that eventually deadlocks the kernel DRM
subsystem.
Activity
synaptics-lspintzyk commentedon Mar 3, 2026
This won't be a problem of double connect. Imo this warning should be raised only when other process tries to connect simultaneously.
The drmWaitVBlank error is more likely to cause that kind of issues with gnome. Can you check if device is still accessible via ssh?
Will restarting gdb when the issue happens recovers?
apilot commentedon May 9, 2026
Same issue on Gentoo (kernel 6.18.26, evdi 1.14.15, Hyprland)
Experiencing the same "Double connect" freeze on a different distro and compositor.
System
Symptoms
evdi_painter_connectlogs "Double connect"kill -9ineffective)hyprctl monitors)card2-DVI-I-1showsconnectedbutenabled: disabled,dpms: Offjakub-prussak-synaptics commentedon May 12, 2026
Hi @apilot , "Double connect" may not be the culprit here. Could you reproduce the bug, collect the logs with
DLSupportTool.shand post them either here or send them to Technical-Enquiries@synaptics.com? We'll take a deeper look at them.melynx commentedon Jul 14, 2026
I am seeing a similar issue on Gentoo, although in my case it becomes a complete system hard lock rather than only losing the EVDI connector.
System:
7.0.13-gentoo-dist6.3.0-481.15.00.55.3on Wayland17e9:ff0b), 1920×1080@60evdi initial_device_count=0The hard locks only appear when the DisplayLink/EVDI display is attached. I have also occasionally seen black rectangles flicker briefly on the monitors while it is attached.
I have observed
Double connectduring EVDI initialization, but it also occurs on boots where DisplayLink starts and operates normally. I therefore agree that it is probably correlated startup noise rather than the direct cause.Across the boots examined so far, four DisplayLink-active boots ended abruptly, while an intervening boot without EVDI shut down normally.
One earlier occurrence looked like this:
Double connectThere was no recorded Xe timeout/reset, DRM timeout, kernel panic, OOM, watchdog event, Hyprland crash, or pstore record.
I then reproduced the problem again with Synaptics advanced DisplayLink logging enabled. Another Linux server monitored the laptop with ping and SSH probes every 10 seconds.
Important: this second, instrumented reproduction did not involve suspend or resume.
It was a fresh boot at 15:44:42. No suspend occurred between boot and the hang approximately 46 minutes later. The only resume-related journal entry was systemd’s normal boot-time hibernation-resume probe, which reported that it could not resume and continued the ordinary boot process.
Therefore, although the earlier incident occurred shortly after an s2idle resume, suspend is not required to trigger the problem.
Reproduction timeline:
S) state, the DisplayLink service was active, and the EVDI connector was connectedThis answers the SSH question: the device was not accessible over SSH during the hang. ICMP stopped responding at the same time, so I could not collect a live stack trace or test restarting DisplayLinkManager or the display manager.
Since this system uses Hyprland/greetd rather than GNOME/GDM, the equivalent display-manager test would be restarting greetd, which terminates the graphical session. That was not possible because the whole machine was unreachable.
The previous-boot journal ends abruptly without an orderly shutdown. It contains no kernel panic, oops, GPU timeout/reset, hung-task warning, watchdog report, or final EVDI/DRM error. The last ordinary kernel message was several minutes earlier.
The fact that the final DisplayLink debug segment stopped roughly four seconds before the last successful SSH probe may be relevant, although the proprietary logs need to be decrypted by Synaptics before drawing any conclusion.
I generated a post-reset
DLSupportTool.sharchive containing:Bundle details:
44,128,825bytes7c6c1c5b23c37e14a10d8aa0f1ca22fa01858d8db29abc40a12001d7e109b326Because the archive contains full dmidecode, journal, process, EDID, and hardware-identification data, I would prefer to send it privately to
Technical-Enquiries@synaptics.com, referencing this issue, rather than attach it publicly.Please let me know if you would also like a reproduction using a crash kernel/kdump configuration or any additional EVDI/DRM tracing.
synaptics-lspintzyk commentedon Jul 14, 2026
You may try reproduce this issue with this PR #562
It may help for issues like this warning:
gnome-shell: Failed to determine deadline: drmWaitVBlank failed: Unknown error -1
Although I doubt DisplayLinkManager can cause system freeze, it is normal process. Its logs won't help to find the problem. Also Double connect is just message that DisplayLinkManager is calling twice connect DRM_EVDI_CONNECT ioctl.
In theory missing vblank event not raised by evdi can cause a compositor hang, but that should be solved by gdm/greetd restart.
What you can do is to enable drm debug logs and try to find a drm ioctl that is causing this hang.