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, sangy)
Last Packager: dvzrv
Votes: 177
Popularity: 2.95
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 ... Next › Last »

dvzrv commented on 2020-10-21 21:47

@jempe: virtualbox is known to break quite frequently. I'd suggest using something more integrated (e.g. qemu) if you can.

jhernberg commented on 2020-10-21 21:27

Well just don't run this version! :) Wait until the major problems are fixed!

jempe commented on 2020-10-21 20:38

It's doesn't boot if virtualbox-host-dkms is instaled...

dvzrv commented on 2020-10-21 15:50

As @jhernberg has mentioned earlier, please be aware of the nvidia related limitations irt the kernel > 5.9 (see related news article).

Note: The upstream of this PKGBUILD has now changed to https://gitlab.archlinux.org/dvzrv/linux-rt, which is a mirror of the canonical upstream. Here I apply Arch Linux specific patches on top of the canonical upstream releases and tag them specifically afterwards.

This ensures a less complicated workflow (all sources soon integrated) and as the upstream pace increased recently it also means not downloading tons of Gb of sources every time (but only once). This is how core/linux and extra/linux-{hardened,zen} are handled btw.

jhernberg commented on 2020-10-21 08:05

5.9 has problems with nvidia among other things, for instance cuda and opencl are broken. My recommendation is to wait with the upgrade until there is a compatible nvidia driver, and other miscellaneous problems have been taken care or.

dvzrv commented on 2020-09-03 19:03

@Ralf_Mardorf: Sorry for the late reply. I have been very busy and then on vacation.

The CONFIG_HZ=1000 setting is indeed thought to improve performance under certain workloads (and it doesn't seem to have much of a negative effect altogether). Note, that according to this article the effects of a higher resolution timer might be diametral on systems with high I/O.

If you encounter any issues let me know!

If you have time to do benchmarks between this setting and e.g. the default CONFIG_HZ=300, please do share!

Ralf_Mardorf commented on 2020-08-23 14:56

I missed #comment-745316, which probably is the reason to revert to 1000 Hz.

However, it's puzzling that when using USB MIDI devices, a faster USB polling rate does improve xrun issues of an audio device. Apart from this, I couldn't find information to which extend CONFIG_HZ is related to the USB polling rate.

Ralf_Mardorf commented on 2020-07-19 14:54

Hi, what's the reason for reverting to CONFIG_HZ=1000?

FWIW due to at least dkms building virtualbox-bin modules issues with 5+ kernels, I stay with 4.19+ kernels. At the moment I've got 4.19.127-rt55 and 4.19.132-rt59 installed, both with CONFIG_HZ=300.

aquilarubra commented on 2020-06-23 15:53

I still find issues with dkms modules. I tried now in 3 different computers, with one of them being AMD.

Results: In 1 Intel and one AMD I can load the nvidia dkms, but not the virtual box dkms. In the third one, I can load none. Errors may differ slightly, but basically disk detection is lost and the kernel cannot find the filesystem.

Marc.2377 commented on 2020-06-23 09:16

@habys: Would you happen to know if the xruns I'm getting on my USB soundcards can be expected to improve by raising the polling frequency in the same manner?

(edit) answering myself, after testing: no it doesn't. But I found the culprit. Running jack in duplex mode (default) results in clock drift between input and output. Running in playback only gets rid of xruns, and I can still manage to have capture by running 'alsa_in' on the same soundcard.