DRM patch for kernel 5.14.x not included in 17.1 tools update

Discussion in 'Linux Virtual Machine' started by Mark Fine, Oct 15, 2021.

  1. Mark Fine

    Mark Fine Pro

    Messages:
    482
  2. serv

    serv Forum Maven

    Messages:
    817
    Mark,
    PD 17.1 is relying on virtio-gpu/virGL device for graphics starting with kernel 5.10. prl_vid is not meant to be built in 5.14 at all, no patches are needed. Tools upgrade should have taken care of removing previous prl_vid.ko and setting things up appropriately.
    Would you mind generating a problem report and posing ID here?
     
    ShawnC4 likes this.
  3. Mark Fine

    Mark Fine Pro

    Messages:
    482
    PROBLEM REPORT: IT'S BROKEN
     
  4. Mark Fine

    Mark Fine Pro

    Messages:
    482
    Honestly... forcing your long-time paying customers to adhere to some bureaucratic bs is terribly annoying. You have all the information needed about VM, kernel version, what the problem is, etc. YOU'RE the Parallels employee. How about YOU fill out the report.
     
  5. Mark Fine

    Mark Fine Pro

    Messages:
    482
    You're going to make us all jump through hoops just to say "Sorry, we don't support kernel 5.14.11" or some nonsense.
     
  6. serv

    serv Forum Maven

    Messages:
    817
    1. Problem report is a package of logs and configuration data that we use to figure out what went wrong. It is designed to avoid you jumping through hoops to collect bits of information manually. Generating a report takes a few clicks and you don't need to fill anything: https://kb.parallels.com/9058.
    2. It may sound bureaucratic to request a report, but most of the time we lack psychic powers to guess the root cause without additional information. Example:
    PROBLEM REPORT: IT'S BROKEN
    From what I know problem reports do work, I can see them coming in in real time. So more information is needed to figure it out. How exactly is it broken? Did you get some error message when sending a report?
    3. Kernel 5.14 is supported, it's been tested. It just doesn't need the patch you think is missing. I ran Fedora 34 myself to make sure the new graphics stack works in 17.1, no bs. That's not to say you don't have a problem, but the reason is not exactly obvious. And I'm back to needing more information.
     
  7. Mark Fine

    Mark Fine Pro

    Messages:
    482
    Clearly, it doesn't work. Here's your bloody report ID: 381231349. Have fun with my personal information.
    I've removed Parallels Tools, perhaps permanently in Linux, because this kind of thing happens every. stinking. time.
    I'm done with this kabuki dance.
     
  8. serv

    serv Forum Maven

    Messages:
    817
    According to system log you still have prl_vid module loaded into 5.14 kernel. That module should have been removed by tools installer v17.1 and not re-installed, yet it's there for you. I've ran Fedora/PD through several upgrade sequences but couldn't get it into similar state.
    The solution would be to clean up prl_vid from /usr/lib/modules and rebuild initramfs, which is what you've already done I presume.

    To reiterate: since PD 17.1 prl_vid module, Parallels GL libraries and Xorg modules are only installed for kernels prior to 5.10. Distributions based on (or updated to) newer kernels are migrated virgio-gpu/virGL graphics stack.
     
  9. Mark Fine

    Mark Fine Pro

    Messages:
    482
    So, here's part of the problem: For the longest time I suspected that the installer script wasn't cleaning up the directories before it installed to, and especially after it uninstalled.

    After your note, I did a little searching, having used the installer to remove Parallels Tools from the VM just yesterday I assumed it would clear out the extra directories, but it didn't. The prl kernel extensions were still in all three kernel/extra directories. So I tried an experiment to re-install. Afterwards, only a few the extensions were dated 16 Oct, but there were a few there left over with a date of 15 Oct from yesterday, including prl_vid.ko.xz.

    So I went through and cleaned house: Deleted all parallels_tools directories from /usr/src and cleaned out all of the prl extensions from the three active kernels' /usr/lib/modules/5.14.[9,10,11]-200.fc34.x86_64/extra directories. I also made sure nothing was in the weak-updates directories, because those used to be used. Then I ran the installer and checked to see what was done. It re-created just the /usr/src/parallels_tools-17.1.0.51516 directory, and only installed to /usr/lib/modules/5.14.11-200.fc34.x86_64/extra directory as shown below:

    Screen Shot 2021-10-16 at 6.58.48 PM.jpg

    As you can see, nothing was installed to the other three kernels' extra directories and didn't even delete the uncompressed ko's.
    Then I ran the installer again to finally finish the job.

    Screen Shot 2021-10-16 at 7.06.11 PM.jpg

    It seems to be working, but I can't possibly be the only one with this issue. There are several reports of booting into an unresponsive black screen in the past, and this is the likely reason why. The installer script should delete all prl_*.ko and prl_*.ko.xz files prior to an install (and especially after an uninstall) to prevent these kinds of problems. Why I had to run the installer twice to complete the job is yet another story.
     
  10. Mark Fine

    Mark Fine Pro

    Messages:
    482
    dnf updated kernel to 5.14.12, but Parallels Tools didn't rebuild and /usr/lib/modules/5.14.12-200.fc34.x86-64/extra is empty. Having to do it manually.
    On top of that, I'm going to add to the fun by saying Fedora 35 is basically out (full release isn't until the 26th)... now the real fun begins.
    What a hot mess...
     
  11. (GalaxyMaster)

    (GalaxyMaster) Hunter

    Messages:
    119
    @Mark Fine, it is working perfectly! Finally, Parallels Inc. got rid of that duct tape and sticks NIH solution and aligned with the rest of the world on how to enable acceleration inside a guest. However, for an existing VM it is a pain to enable the stuff properly. Please see another thread I am going to write in 5 minutes or so on VirtGL, but in short -- you need to: remove `prl_vid.ko` module from you kernel, revert lib{EGL,GL,gbm}*.so to their original version as installed by your distro, remove `prl*` drivers from your Xorg's /usr/lib*/xorg/modules/drivers, and clean up /usr/share/X11/ from configuration dropped by Parallel Tools. Once it is done, you will need to shutdown your VM, create a new one (it is a bit tricky to describe, but you can create an empty custom VM using "create from ISO" and then instructing PD to use a blanks VM) and attach your disks back. From that point on you will be running Virgil.
     
  12. Mark Fine

    Mark Fine Pro

    Messages:
    482
    @(GalaxyMaster) I Managed to update to F35 and kinda did all that, but in a different way:
    1. Did the dnf upgrade, but noticed it reverts the kernel to 5.14.10(-300) for F35 - this actually complicates things because of the way the Tools installer enumerates kernels. Lots of fun because I hadn't changed the hypervisor (See below).
    2. Removed Parallels Tools using /run/media/mark/Parallels\ Tools/installer (the text one, not the gui)
    3. Erased all older F34 kernels using `dnf erase` as well as deleting their /usr/lib/modules/ directories
    4. Ensured current kernel extra was blank.
    5. Deleted the version Tools leaves in /usr/src/
    6. ran /run/media/mark/Parallel\ Tools/installer again to do the install, then reboot when it finishes.
    7. After the first reboot, shut it down, then restart it again. I have no idea why this works, but it always takes two restarts to take hold.

    I've deduced that if it boots using small, barely readable fonts along the left hand of the screen and then turns upside down just prior to the login screen, it's not really booting into Virgil correctly. Should be a larger, very readable font (I'm not THAT old) with obvious margins on left and right.

    Only other thing I ended up doing was to change the hypervisor from Apple to Parallels... seems that using the Apple one was causing CPU lockups which would only unclog after a spacebar press.

    All this and no big red bus...
     
  13. Mark Fine

    Mark Fine Pro

    Messages:
    482
    I'm wrong about the tiny font being an indication. Ran the tests in your post and seems virgil is indeed being used, even after a boot with tiny fonts.
    Just so happens that's the font used when no Tools is installed so I made that years-old mental connection, forgetting that video is no longer part of Tools. #doh
     
  14. Mark Fine

    Mark Fine Pro

    Messages:
    482
    After running this update for the past several days, to include a smoother than normal (read: 'mostly dramaless') upgrade to FC35, I have to say that I'm rather impressed. My apologies for being rude, @serv. I feel like years upon years of biannual frustration with Parallels not keeping up with Linux has finally been solved.
     
    (GalaxyMaster) and ShawnC4 like this.
  15. Mark Fine

    Mark Fine Pro

    Messages:
    482
    ...Also helps if I clean up /var/lib/dkms/parallels-tools/ when there's a kernel update. It still had references to 17.0.1 as well as older kernels that I've long deleted.
    So when dkms runs on a kernel update it fails when it can't find dkms.conf for 17.0.1. ‍♂️
     
  16. Mark Fine

    Mark Fine Pro

    Messages:
    482
    ...Also helps a little more if you edit 'prl_vid' from /etc/dracut.conf.d/parallels-tools.conf. so you don't continue to get this during kernel updates:
    ---------8<--------
    dracut-install: Failed to find module 'prl_vid'
    dracut: FAILED: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.LnuYwy/initramfs -N prl_fs|prl_fs_freeze --kerneldir /lib/modules/5.14.18-300.fc35.x86_64/ -m prl_tg prl_vid prl_eth
     
  17. andrewsi1

    andrewsi1 Bit poster

    Messages:
    3
    Same issue here.
     
  18. Mark Fine

    Mark Fine Pro

    Messages:
    482
    Updated to 17.1.1:
    1. Although /var/lib/dkms/parallels-tools/17.1.1.51537 contained a directory for the current kernel (kernel-5.15.5-200.fc35.x86_64-x86_64) it was still a linked to 17.1.0.51516 in the directory. Only the previous 2 kernels were properly linked to 17.1.1.51537 in /var/lib/dkms/parallels-tools.
    2. /var/lib/dkms/parallels-tools/17.1.0.51516 was never removed.
    3. /usr/src likewise, still contained a parallels-tools-17.1.0.51516 directory.

    So, I guess we're still left to clean up the (complex) battlefield after every update instead of the install script doing it for us.
     

Share This Page