Skip to content
Snippets Groups Projects

wrap: execute nvidia-modprobe before entering the container

Merged Ludovico de Nittis requested to merge wip/nvidia_modprobe into master
1 unresolved thread

Fixes: #59 (closed)


Note that with the current PRESSURE_VESSEL_RELAUNCH_CONTAINER option, if nvidia-modprobe doesn't succeed, we probably end up trying to run it two times (one for the setup and one for the actual game). The only real side effect of this should be a double cannot run nvidia-modprobe message in the log.

I implemented this following the discussion on #59 (closed) but I didn't actually test this patch because I don't have a system with a Nvidia GPU.

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
    • Resolved by Simon McVittie

      I implemented this following the discussion on #59 (closed) but I didn't actually test this patch because I don't have a system with a Nvidia GPU.

      Please could you do a manual test by locally hacking the check to look at /sys/module/bluetooth/version (or some other module with a version that you do have) instead of /sys/module/nvidia/version, and adding a stub modprobe to your PATH?

      Edited by Simon McVittie
  • added 35 commits

    • 2061a644...630a52f7 - 32 commits from branch master
    • e5fafaf2 - wrap: execute nvidia-modprobe before entering the container
    • 723f6016 - utils: refactor pv_capture_output into a more generic pv_run_sync
    • 56402aca - wrap: execute nvidia-modprobe before entering the container

    Compare with previous version

  • added 2 commits

    • 3302f570 - utils: refactor pv_capture_output into a more generic pv_run_sync
    • 2a37c493 - wrap: execute nvidia-modprobe before entering the container

    Compare with previous version

  • Simon McVittie resolved all threads

    resolved all threads

  • Simon McVittie
  • Simon McVittie
    Simon McVittie @smcv started a thread on an outdated change in commit 3302f570
  • 206 212 NULL, NULL,
    207 213 &output,
    208 214 &errors,
    209 &wait_status,
    215 &exit_status,
    • No, this is still a wait status. This was wrong in pv_bwrap_run_sync() and correct in pv_capture_output().

      The (out) parameter of wait() and waitpid() gives you a wait status, and then you decode the wait status into either an exit status if WIFEXITED, a terminating signal if WIFSIGNALED, or some mysterious other thing.

      Implementation detail: on Linux, and I think every other known Unix OS, the wait status is:

      bit# | 31 ... 24 | 23 ... 16 | 15 ... 8    | 7 | 6 ... 0 |
      -----|-----------|-----------|-------------|-------------|
           | unused    | unused    | exit status | C | signal  |

      where C is 1 if the process dumped core.

    • Ah right, thanks for the explanation. I saw that they were named differently in the two implementations but I went with exit_status because that's what the parameter was called in the g_spawn_sync().

    • Yeah, that's wrong too. I should get that fixed in GLib, if it wouldn't be considered to be an introspection API break.

    • Please register or sign in to reply
  • Thanks, the refactoring improves this a lot. A couple of minor issues in the refactored pv_run_sync(), then this is good to merge.

  • added 2 commits

    • d2b907aa - utils: refactor pv_capture_output into a more generic pv_run_sync
    • b898cdd3 - wrap: execute nvidia-modprobe before entering the container

    Compare with previous version

  • Ludovico de Nittis resolved all threads

    resolved all threads

  • Simon McVittie enabled an automatic merge when the pipeline for b898cdd3 succeeds

    enabled an automatic merge when the pipeline for b898cdd3 succeeds

  • Simon McVittie mentioned in commit 9533e588

    mentioned in commit 9533e588

  • Please register or sign in to reply
    Loading