Struggling with some devices often not functioning upon suspend, I came across the SE U&L question of reloading drivers.
In my case, a few devices are not detected, and I can see the driver (displaylink-driver.service) is loaded but inactive/dead. So, is it possible to start drivers up again?
$ lsusb
# missing usb devices (detected by $ lsusb before the issue)
Bus 004 Device 005: ID 17ef:a357 Lenovo USB3.1 Hub
Bus 004 Device 004: ID 17ef:a359 Lenovo ThinkPad Lan
Bus 004 Device 003: ID 17e9:6015 DisplayLink ThinkPad Hybrid USB-C with USB-A Dock
Bus 004 Device 002: ID 17ef:a356 Lenovo USB3.1 Hub
$ sudo systemctl status displaylink-driver.service
● displaylink-driver.service - DisplayLink Driver Service
Loaded: loaded (/lib/systemd/system/displaylink-driver.service; static)
Active: inactive (dead)
May 26 14:50:56 debija systemd[1]: Starting DisplayLink Driver Service...
May 26 14:50:56 debija systemd[1]: Started DisplayLink Driver Service.
May 26 18:03:21 debija systemd[1]: Stopping DisplayLink Driver Service...
May 26 18:03:22 debija systemd[1]: displaylink-driver.service: Succeeded.
May 26 18:03:22 debija systemd[1]: Stopped DisplayLink Driver Service.
May 26 18:03:22 debija systemd[1]: displaylink-driver.service: Consumed 41min 25.761s CPU time.
lspci
show any difference between working vs. not? If it does, the TB might need atbtadm approve-all
or similar after waking from suspend. – telcoM May 30 '23 at 08:09tbtadm
on my system, nor doesapt search tbtadm
return anything. Please see the output oflspci
in the question about the problem: https://unix.stackexchange.com/questions/746739/why-after-suspend-only-sometimes-not-detect-usb-or-deactivates-driver-and-how – Johan May 30 '23 at 09:53tbtadm
might be in a package namedthunderbolt-tools
. I guess the dock fundamentally connects using the Thunderbolt protocol, and the "missing" USB devices are provided by a Thunderbolt-to-USB adapter within the dock. Once all the hardware connections are properly woken up from suspend (+ re-authorized if necessary), the missing USB devices should come back and be usable again, so restarting the DisplayLink driver service would have to be the last step in the wake-up process. – telcoM May 30 '23 at 10:24evdi
) that allows to create a "virtual display device" with a userspace backend. But here it looks like the death of the driver service might be a consequence of the DisplayLink USB hardware not being accessible any more after the wakeup. – telcoM May 30 '23 at 10:37apt install thunderbolt-tools
.$ sudo tbtadm approve-all
returnsFound domain "/sys/bus/thunderbolt/devices/domain0"
. Butlsusb
still does not detect the four devices. – Johan May 30 '23 at 12:53thunderbolt-tools
are absolutely needed - but on PCs, the system firmware can do most of that job. But if the firmware retains control of the Thunderbolt controller(s), and fails to wake them correctly after suspend,tbtadm
might not be able to fix it. Then a BIOS update might be your only hope. But just for information, trytbtadm devices
in both working and non-working states. Any info at all? Differences? – telcoM May 30 '23 at 13:11tbtadm devices
show no output when the whole thing works as desired (before suspending twice). It seems so odd it won't get back after second suspend, but the first it will. I'm glad I just got hibernate to work, then I can use that as an alternative. Btw, I did not do anything else thantbtadm approve-all && lsusb
-- did I have to do anything else? Did you notice I have installedtlp
, and there are possible solutions like autosuspend, blacklist etc.? Would you assert these are not solutions in my case? – Johan May 30 '23 at 14:12