Package Base Details: linux-rt

Git Clone URL: (read-only, click to copy)
Submitter: schivmeister
Maintainer: jhernberg (dvzrv, sangy)
Last Packager: dvzrv
Votes: 176
Popularity: 2.38
First Submitted: 2011-08-09 20:03
Last Updated: 2021-05-18 20:55

Pinned Comments

dvzrv commented on 2021-01-12 21:52

The repository for linux-rt and linux-rt-lts has moved to a new location.

If you use the custom repository, please update your pacman.conf accordingly, as the other one is going away by the end of the month (January 2021)!

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 ... Next › Last »

habys commented on 2020-05-15 00:16

Hey {jhernberg, dvzrv} would you consider

diff --git a/config b/config
index 381a044..7057c9c 100644
--- a/config
+++ b/config
@@ -457,8 +457,8 @@ CONFIG_EFI_MIXED=y
 # CONFIG_HZ_100 is not set
 # CONFIG_HZ_250 is not set
-# CONFIG_HZ_1000 is not set
+# CONFIG_HZ_300=y

The default relatively slow USB poll rate on a realtime audio box causes XRUNS when using USB MIDI devices.

aquilarubra commented on 2020-03-21 11:36

Tried virtualbox-bin, but same behavior. Loading modules on demand hangs system. I also have the nvidia dkms, but it shouldn't matter. The issue seems uefi-virtualbox related.

Ralf_Mardorf commented on 2020-03-21 08:24

Hi, I stopped building new 5.4 kernels and will continue with kernels > 5.4. I'm still building new 4.19 LTS releases and use those instead. The kernels are pretty much the same as the AUR kernels, just with minimal personalised changes and I'm using virtualbox-bin from AUR. Btw. I can boot into 5.4 kernels without efi and no issue at all, but virtualbox guests don't start. Ever since I can remember I load the modules on demand, not at startup.

$ pacman -Q linux-rt{,-pussytoes,-cornflower,-securityink} virtualbox-bin|cut -d\  -f2

aquilarubra commented on 2020-03-20 20:18

Any idea why virtualbox-host-dkms is incompatible? Initially it gave me a uefivars error at boot. I solved that by adding efi=runtime to the kernel. Then, as udev loads the virtualbox module, the system hangs with a ton of errors. The uefi disks are not recognized. I also tried disallowing the dkms module to load at boot. Then it boots, but as I do a modprobe vboxdrv, everything hangs. I think the incompatibility is between uefi and virtualbox. I see that Manjaro created a package with extra modules for virtualbox with the rt kernel and it is reported to work.

Ralf_Mardorf commented on 2020-03-14 17:39

Hi, the package contains the kernel in

$ pacman -Ql linux-rt | grep vmlinuz
linux-rt /usr/lib/modules/5.4.22-rt13-1.0/vmlinuz

Where the package is stored depends on your makepkg.conf

$ grep PKGDEST /etc/makepkg.conf

If you install the package, the kernel is installed to

$ diff /boot/vmlinuz-linux-rt /usr/lib/modules/5.4.22-rt13-1.0/vmlinuz; echo $?
$ ls -hl /boot/vmlinuz-linux-rt /usr/lib/modules/5.4.22-rt13-1.0/vmlinuz
-rw-r--r-- 1 root root 5.9M Mar  4 10:09 /boot/vmlinuz-linux-rt
-rw-r--r-- 1 root root 5.9M Mar  4 06:41 /usr/lib/modules/5.4.22-rt13-1.0/vmlinuz

Fourstepper commented on 2020-03-14 16:36

Where does the kernel go once it's compiled?

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 and linux-rt-headers 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.