Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

systemd service: timing issues - 'switch auto' runs before egpu is connected by bolt #50

Closed
theironrobin opened this issue Sep 29, 2020 · 6 comments

Comments

@theironrobin
Copy link

theironrobin commented Sep 29, 2020

Great work on this project! Only issue with me is that the auto-detect doesn't work for me. In order to get my eGPU working correctly I need to manually set the mode to 'egpu', disable the egpu.service, then reboot.
If i set it to auto with the service enabled, it always chooses the internal symlink.

eGPU is a Razer Core with a AMD RX 580. Machine is a System76 Darter Pro with 10th gen i7 + Intel integrated graphics. Software is Ubuntu Focal (PopOS)

@hertg
Copy link
Owner

hertg commented Sep 29, 2020

Hey Alex,

This sounds very similar to another issue #16 that was reported a while ago.
Did you just recently install egpu-switcher? And did you install via PPA or via git/make?

Unfortunately, I can't provide you with any solutions based on the information you reported, but I can try to guide you into the right direction. It sound like a timing issue, meaning that the egpu-switcher runs before your eGPU is successfully connected to your notebook.

  1. Have a look at the conversation in issue Need to reboot twice each time for switching gpu #16, maybe you'll find a solution there.
  2. Have a look at your currently enabled egpu.service (cat /etc/systemd/system/egpu.service). Does it look like this?
    [Unit]
    Description=EGPU Service
    Before=display-manager.service
    After=bolt.service
    
    [Service]
    Type=oneshot
    ExecStart=/usr/bin/egpu-switcher switch auto
    
    [Install]
    WantedBy=graphical.target
    
  3. How is your Thunderbolt Security configured in the BIOS? You can check in the BIOS directly or run the following command if you have boltctl installed.
    boltctl config global.security-level
    
    I've had such timing issues myself in the past, but didn't experience any with the latest version of egpu-switcher and with my current Thunderbolt Configuration:
    I did set the Thunderbolt Security Level to user (That's most likely the default, it requires user authorization of new TB devices) and enabled Pre-Boot ACL (Allows the TB devices that were authorized by the user to connect before boot - This might affect connection timing after boot) in the BIOS. The exact names of those settings might vary on your system

@theironrobin
Copy link
Author

theironrobin commented Sep 30, 2020

used ppa.
yes my service looks like that.
boltctl returns 'user'

@hertg
Copy link
Owner

hertg commented Oct 1, 2020

Try setting TB Security to none temporarily, and see if the issue persists.
If this "solves" the issue, re-enable TB Security by setting it back to user and enable Pre-Boot ACL.
If that solves the issue, i would recommend to leave it at that.

If it doesn't, you could try editing the egpu-switcher (/usr/bin/egpu-switcher) by adding a sleep 5s (play around with the amount of time a little bit) in the is_egpu_connected() method. Make sure to add it before the if statement (on line 146 for example).

egpu-switcher/egpu-switcher

Lines 131 to 156 in 4ae0d5d

function is_egpu_connected() {
# read pci id from xorg.conf.egpu
declare egpu_pci_id=$(cat $xfile_egpu | grep -Ei "BusID" | grep -oEi '[0-9]+\:[0-9]+\:[0-9]+')
# create an array by splitting the BUS-ID on ':'
declare busArray=(${egpu_pci_id//:/ })
declare bus1d=${busArray[0]}
declare bus2d=${busArray[1]}
declare bus3d=${busArray[2]}
# convert dec to hex
declare bus1h=$(printf "%02x" $bus1d)
declare bus2h=$(printf "%02x" $bus2d)
declare bus3h=$(printf "%01x" $bus3d)
if [ $(lspci | grep -iEc "$bus1h:$bus2h.$bus3h") -eq 1 ]; then
print_info "EGPU is ${green}connected${blank}."
gpu_connected=1
hex_id=$bus1h:$bus2h.$bus3h
#return 1
else
print_info "EGPU is ${red}disconnected${blank}."
gpu_connected=0
fi
}
)

Report back your findings, and I'll see how I can improve egpu-switcher based on your feedback.
If none of the above workarounds solve your issue, I'm not sure what the cause of your problem might be.

@adback03
Copy link

adback03 commented Oct 3, 2020

So I'm having the exact problem, and can confirm that adding the sleep 5s where specified fixes the issue of the auto switcher not selecting the egpu after booting up. Unfortunately, I still can't get the video to output to my external monitor. The monitor is detected by the machine, but stays black.

My egpu is also a Razer Core X Chroma with a AMD RX 580. My machine is a Razer Blade which has two internal GPUs - an intel one and an nvidia gtx 1060.

Once I booted back up, the symlink was correctly pointing to the xorg.conf.egpu but my machine was also noticeably laggy (with no video output still on my external monitor). I've since switched back to the internal only, as I'm not quite sure what else to try here.

@hertg
Copy link
Owner

hertg commented Oct 3, 2020

@adback03
Thanks for the feedback, that confirms that there are still timing issues.
Did you also try to play around with the Thunderbolt Security Levels? Did that change anything or did it stay the same?

Unfortunately, I don't know what the problem could be with your monitor. I'm guessing it is connected directly to the eGPU? If so and if it get recognized by xrandr then egpu-switcher runs correctly, and the issue seems to be a problem with your monitor configuration. I'm not an expert with xrandr / monitor-setups so I can't really help you with that, sorry.

@hertg hertg changed the title 'auto' setting issue systemd service: timing issues - 'switch auto' runs before egpu is connected by bolt Oct 3, 2020
@theironrobin
Copy link
Author

I updated to Pop!_OS 20.10 and installed latest code from source and my timing issues seem to be cleared up now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants