An update for all repositories

Another batch of updates to the repositories:

  • MakeMKV has been updated to version 1.8.8, according to the release notes it should contain proper support for Fedora’s OpenSSL package which generated SCSI errors with BluRay drives. The same version has been pushed to the CentOS/RHEL 6 repository, but due to very old ffmpeg packages in this distribution, there is no FLAC encoder for 24-bit audio in the build.
  • The Nvidia driver is now built also for Fedora 21 (rawhide) and for CentOS/RHEL 7 with the updated beta drivers directly from Nvidia (version 334.16). According to the release notes, the Nvidia DDX driver for X no longer loads the kernel module internally but relies on the nvidia-modprobe command in the system. Apparently this is not true, because the libraries try to load the kernel modules also with the system modprobe command if available. On Fedora 21 and RHEL 7 there is not yet aKMOD or kABI modules support as they are not available in their respective repositories; you have to rely on dkms-nvidia for installing the kernel module(s) on those distributions.
  • The CDRtools suite has been updated to version 3.01a22.
  • The Steam package has been updated to version, the same build has been pushed to RPMFusion.
  • The Flash plugin package has been updated to version and Skype has been updated to version Both versions have also been pushed to RPMFusion in the form of lpf packages.

14 thoughts on “An update for all repositories

    1. Not really, they are beta drivers, so I added them to the non-stable distributions. Also, I’ve built them for my Fedora 20 systems but they produce artifacts with web pages and I had to revert to the current stable.

  1. Any updates on the builds of NVidia drivers for fc20 with kernel 3.13.3-201.fc20?

    make[1]: *** [_module_/tmp/akmodsbuild.Lj0szMmQ/BUILD/nvidia-kmod-331.38-x86_64/_kmod_build_3.13.3-201.fc20.x86_64/uvm] Error 2
    make[1]: Leaving directory `/usr/src/kernels/3.13.3-201.fc20.x86_64'
    NVIDIA: left KBUILD.
     nvidia-uvm.ko failed to build!
    make: *** [nvidia-uvm.ko] Error 1
    1. An update to aKMOD and DKMS modules has been already pushed to the repositories yesterday, 331.38-2. Update 331.49 is coming.

  2. I’ve just updated to akmod-nvidia latest version, but now I’m getting hard lockups with 3.13 – so much that I had to go back to 3.12. I also saw that NVidia has released a new version of 331.49 today, so I will wait until you build it to give a try.

      1. Hmmm, no dice. 331.49 locks hard on 3.13.3-201.fc20. Must be something kernel-related, since 331.38 works normally on 3.12.10-300.fc20. I couldn’t build 331.49 on 3.12.10-300.fc20, since the build ended on error. Will check what it is and will report back. In the meantime, I’ll open a bug against rpmfusion since I get the very same hard lockup with their packages on th 3.13 kernel.

        1. Again, 331.49-1 and 331.38-2 work fine here (two laptop, one desktop in SLI mode), no lockups. Are you using any extra parameter on the kernel module or driver (PCIex 3.0, MSI-X interrupts, overclock, etc.)?

  3. My boot cmdline is like this:

    GRUB_CMDLINE_LINUX="$([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rhgb quiet nomodeset nouveau.modeset=0
    rd.driver.blacklist=nouveau crashkernel=128M threadirqs vconsole.font=LatArCyrHeb-16 iommu=pt iommu=1 iommu=fullflush"

    Absolutely no issues with these options until 3.13 has been sumitted as an update. And I’m not overclocking neither using any options for loading nvidia-module.

      1. Can’t do this right now as I’m waiting for some unresumable downloads to complete. Anyway, I verified and there seems to have issues with the “threadirqs” boot option, which I have added to solve the “IRQ XX: nobody cared” problems with snd_hda_intel module. I will try to disable it on the next boot, probably in the next 30 minutes.

  4. Ok, seems that I’ve got to stabilize it right now.

    After disabling ‘threadirqs’ kernel option, I had mplayer locking up while playing videos. Inspecting /var/log/Xorg.0.log I’ve found this:

    [ 305.939] nvLock: client timed out, taking the lock

    Researching about this message I’ve found this:

    Basically, it says to disable hpet and use tsc for the clock source timings. This can be accomplished with the following boot options:

    hpet=disable clocksource=tsc processor.max_cstate=1

    After doing this, system seems to be stable. Should there be any additional problems I will report back.

    My system is a M4A89TD PRO USB3, with an Athlon X6 1075T processor and two video boards, one 9500 GT and the other GT620. I’m running Fedora 20 with the latest kernel and system patches.

Leave a Reply