Open Smeeto13 opened 4 weeks ago
It looks to me like it's a race between how fast (or slow) the eGPU is initialized and how fast the script runs before it gives up. Could you try increasing the number in /usr/share/all-ways-egpu/max-retry
to something like 4 and see if that fixes it for you?
I tried it with /usr/share/all-ways-egpu/max-retry set to 5 and no luck, also I modified the service file to make method 3 run after method 2 to make sure the eGPU is definitely initialized at that point
@Smeeto13
Ok, could you post the output of the command ls /dev/dri
with and without the eGPU attached?
The systemd service functions as expected if started manually after the laptop has booted, Without the eGPU connected I get:
drwxr-xr-x 2 root root 80 Jun 4 12:02 by-path
crw-rw----+ 1 root video 226, 1 Jun 4 12:02 card1
crw-rw-rw- 1 root render 226, 128 Jun 4 12:02 renderD128
When the card is connected I get:
drwxr-xr-x 2 root root 120 Jun 4 12:09 by-path
crw-rw----+ 1 root video 226, 0 Jun 4 12:09 card0
crw-rw----+ 1 root video 226, 1 Jun 4 12:02 card1
crw-rw-rw- 1 root render 226, 128 Jun 4 12:02 renderD128
crw-rw-rw- 1 root render 226, 129 Jun 4 12:09 renderD129
Ok good to know it works if started after the laptop is booted. Method 3 depends on udev being up and initialized. On my system (Fedora 40) this happens early in the boot process, but maybe on your system it happens later? You could try changing the all-ways-egpu-set-compositor.service file to add: After=systemd-udevd.service Otherwise if that doesn't do it I'm not sure what else could be done in the script to fix this.
I've tried that to no success, I'm assuming it is something to do with how the eGPU enclosure is connected on my new laptop as it uses USB4 with iommu security and my old laptop running the same setup software wise used thunderbolt 3 and secure user device authentication
I tried changing the service file so method 3 runs after method 2 in order to verify and the GPU is still not detected by method 3