Package Base Details: linux-rt

Git Clone URL: https://aur.archlinux.org/linux-rt.git (read-only, click to copy)
Submitter: schivmeister
Maintainer: jhernberg (dvzrv)
Last Packager: dvzrv
Votes: 165
Popularity: 0.58
First Submitted: 2011-08-09 20:03
Last Updated: 2020-02-15 10:08

Pinned Comments

dvzrv commented on 2019-05-13 21:17

I have added a signed, unofficial user repository for linux-rt, backed by this PKGBUILD.

You can add it to your pacman.conf with:

[dvzrv]
Server = https://pkgbuild.com/~dvzrv/repo/$arch

I'll try to keep it as up-to-date as possible and retain old versions.

Enjoy!

Latest Comments

1 2 3 4 5 6 ... Next › Last »

kflak commented on 2020-02-15 06:56

@jhernberg: Thanks! I'll give it a go and see if any problems crop up. I'm obviously not going to do a firmware-update during a performance, but will test it thoroughly first to see if it impacts performance.

dvzrv commented on 2020-02-14 17:53

@jt525: I installed nvidia-dkms (and also have other dkms modules) to test and they all built without an issue.

Let me know if this happens again! :)

jt525 commented on 2020-02-14 16:06

@dvzrv: I'm on gcc version 9.2.1+20200130-2. I installed linux-rt 5.4.17.9-3 and linux-rt-headers 5.4.17.9-3 as part of a pacman -Syu, so it wasn't a partial upgrade. I tried reinstalling after running pacman -Syyu and it still breaks on every DKMS install for this version. I'll try rebuilding the package again to see if it changes anything.

edit: rebuilding the package twice fixed the issue. no clue how or why, but I'll take what I can get

jhernberg commented on 2020-02-14 13:43

@kflak. I don't know the details but remember that it was disabled due to possibly causing problems. I suspect that just having it enabled shouldn't cause any problems, but actively using it might cause some extra delays in scheduling. Anything BIOS related is probably a bad idea when needing the lowest kernel scheduling latency possible.

dvzrv commented on 2020-02-14 10:15

@jt525: what is your gcc version?

I can't reproduce your problem and assume, that you did a partial upgrade. Please upgrade your system!

jt525 commented on 2020-02-14 03:19

I can't upgrade to 5.4.17.9-3 because my DKMS modules won't install. Version 5.4.17.9-2 installs just fine. Is there a substantial difference between the two versions, or can I just stay on 5.4.17.9-2 until a new one comes out?

Here's a copy of pacman output while installing DKMS modules:

(3/4) Install DKMS modules
==> dkms install nvidia/440.59 -k 5.4.17-rt9-3-rt
Error! Bad return status for module build on kernel: 5.4.17-rt9-3-rt (x86_64)
Consult /var/lib/dkms/nvidia/440.59/build/make.log for more information.
==> dkms install alx/4.18.16 -k 5.4.17-rt9-3-rt
Error! Bad return status for module build on kernel: 5.4.17-rt9-3-rt (x86_64)
Consult /var/lib/dkms/alx/4.18.16/build/make.log for more information.
==> dkms install wireguard/0.0.20200205 -k 5.4.17-rt9-3-rt
Error! Bad return status for module build on kernel: 5.4.17-rt9-3-rt (x86_64)
Consult /var/lib/dkms/wireguard/0.0.20200205/build/make.log for more information.
==> dkms install acpi_call/1.1.0 -k 5.4.17-rt9-3-rt
Error! Bad return status for module build on kernel: 5.4.17-rt9-3-rt (x86_64)
Consult /var/lib/dkms/acpi_call/1.1.0/build/make.log for more information.
==> dkms install vboxhost/6.1.2_OSE -k 5.4.17-rt9-3-rt
Error! Bad return status for module build on kernel: 5.4.17-rt9-3-rt (x86_64)
Consult /var/lib/dkms/vboxhost/6.1.2_OSE/build/make.log for more information.
==> dkms install alx-wol/5 -k 5.4.17-rt9-3-rt
Error! Bad return status for module build on kernel: 5.4.17-rt9-3-rt (x86_64)
Consult /var/lib/dkms/alx-wol/5/build/make.log for more information.

All the make logs end up identical with these two lines:

cc1: error: incompatible gcc/plugin versions
cc1: error: fail to initialize plugin ./scripts/gcc-plugins/structleak_plugin.so

Any help would be appreciated. Thanks!

kflak commented on 2020-02-13 18:42

@jhernberg: So it might become an issue when doing real-time interactive audio stuff? This is my main reason for using an rt-kernel... So far I haven't noticed any noticable performance issues other than the occasional xrun when pushing the buffer size down below 128, but then again efivars weren't active before... :-)

jhernberg commented on 2020-02-13 18:22

It was disabled for the rt patch as it can hurt the kernel scheduling latency.

kflak commented on 2020-02-13 16:10

@dvzrv: Thanks for adding to the wiki! Very useful to know, especially as it is vital to the functioning of firmware updates. Just curious, though: is there a specific reason for disabling efivars in the rt-kernels? Does it impact performance in any way?

dvzrv commented on 2020-02-12 21:51

@kflak: It seems @Alvo alread provided the answer. Should've checked the mailing list earlier. These questions keep popping up from time to time :)

As a sidenote: I've added it to the wiki (for next time ;-) ).