Package Details: linux-rt-headers

Git Clone URL: (read-only, click to copy)
Package Base: linux-rt
Description: The Linux RT kernel and modules
Upstream URL:
Licenses: GPL2
Submitter: schivmeister
Maintainer: jhernberg (dvzrv, sangy)
Last Packager: dvzrv
Votes: 179
Popularity: 2.44
First Submitted: 2011-08-09 20:03 (UTC)
Last Updated: 2022-08-14 20:59 (UTC)

Pinned Comments

dvzrv commented on 2021-01-12 21:52 (UTC)

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

dvzrv commented on 2022-08-10 07:47 (UTC)

@blackhole: Mainly time reasons. Will hopefully get to it this weekend though.

blackhole commented on 2022-08-03 12:29 (UTC)

Why version 5.18 or 5.19 has not been released here?

Ralf_Mardorf commented on 2022-01-02 09:00 (UTC) (edited on 2022-01-02 09:04 (UTC) by Ralf_Mardorf)

Hi, consider to rewrite the PKGBUILD to get the sources for the vanilla kernel and the rt-patch from, if wanted you can apply additional, e.g. Arch related patches, too, instead of cloning the git repo used by this PKGBUILD. Building it this way 4 GiB tmpfs are usually sufficient, let alone that getting the sources is way faster. This is at least what I'm doing, when using 7.6 GiB tmpfs. Or else, don't build in tmpfs at all, since building the kernel package on a drive doesn't slow down compiling that much. Regards, Ralf

cmc commented on 2022-01-02 08:29 (UTC)

Had 8G tmp space configured and build failed saying out of disk space. Needed to increase available space like so before installing the package (this reverts back on reboot)

mount -o remount,size=48G /tmp

dvzrv commented on 2021-10-11 17:20 (UTC)

@r7v: efivarfs is disabled by default with the patchset.

r7v commented on 2021-10-11 17:04 (UTC)

have to add kernel boot parameter efi=runtime for efivarfs to work

funkmuscle commented on 2021-08-29 21:32 (UTC) (edited on 2021-08-29 21:47 (UTC) by funkmuscle)

yes all of the updates after 5.19 freezes Ardour, Audacity, etc. I keep having to downgrade

Mik commented on 2021-08-02 16:24 (UTC)

Thank you Ralf_Mardorf I am going to try this. That's a good idea.

Ralf_Mardorf commented on 2021-08-02 16:07 (UTC)

Hi Mik, I don't know if the PKGBUILD applies other patches, but the RT patch. If it should apply other patches, too, consider to build from sources by using the kernel source and only applying the RT patch. You likely will still experience the same issue. If so, the linux-rt-users discussion and bug reporting mailing list is the best place to report the issue. Regards, Ralf

Mik commented on 2021-08-02 15:46 (UTC) (edited on 2021-08-02 15:57 (UTC) by Mik)


I have freeze issues with linux-rt(5.13) and linux-rt-lts(5.10). I don't reproduce the issues on the standard prempt kernel (5.13.7) with the exact same operation (build a package). This is the log I get before freezing:

on linux-rt-lts

Aug 02 16:15:46 zik6242 kernel: process '/testcmd.4188.CcILVU/aaa' started with executable stack
Aug 02 16:17:26 zik6242 kernel: intel_powerclamp: Start idle injection to reduce power
Aug 02 16:17:28 zik6242 kernel: sched: RT throttling activated
Aug 02 16:17:28 zik6242 kernel: intel_powerclamp: Stop forced idle injection

Aug 02 16:18:26 zik6242 kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
Aug 02 16:18:26 zik6242 kernel: rcu:         Tasks blocked on level-0 rcu_node (CPUs 0-3):
Aug 02 16:18:26 zik6242 kernel:         (detected by 1, t=60002 jiffies, g=183649, q=679351)
Aug 02 16:18:26 zik6242 kernel: rcu: All QSes seen, last rcu_preempt kthread activity 1 (4295397723-4295397722), jiffies_till_next_fqs=3, root ->qsmask 0x0
Aug 02 16:19:01 zik6242 dbus-daemon[327]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service' requested by ':1.10' (uid=0 pid=10344 comm="sshd: mik [priv]    ")
Aug 02 16:19:01 zik6242 dbus-daemon[327]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.home1.service': Unit dbus-org.freedesktop.home1.service not found.
Aug 02 16:19:01 zik6242 sshd[10344]: pam_systemd_home(sshd:account): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found.

on linux-rt

Aug 02 17:21:46 zik6242 kernel: process '/testcmd.4171.CdXO0y/aaa' started with executable stack
Aug 02 17:22:35 zik6242 kernel: intel_powerclamp: Start idle injection to reduce power
Aug 02 17:22:35 zik6242 kernel: NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #02!!!
Aug 02 17:22:35 zik6242 kernel: NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #02!!!
Aug 02 17:22:35 zik6242 kernel: NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #02!!!
Aug 02 17:22:35 zik6242 kernel: NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #02!!!
Aug 02 17:22:35 zik6242 kernel: NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #02!!!
Aug 02 17:22:35 zik6242 kernel: NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #102!!!
Aug 02 17:22:35 zik6242 kernel: NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #102!!!
Aug 02 17:22:35 zik6242 kernel: NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #102!!!
Aug 02 17:22:35 zik6242 kernel: NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #102!!!
Aug 02 17:22:35 zik6242 kernel: NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #102!!!
Aug 02 17:22:35 zik6242 kernel: sched: RT throttling activated
Aug 02 17:22:36 zik6242 kernel: intel_powerclamp: Stop forced idle injection

on the prempt kernel I get:

Aug 02 17:29:16 zik6242 kernel: process '/testcmd.4175.6bb3cX/aaa' started with executable stack
Aug 02 17:35:22 zik6242 kernel: perf: interrupt took too long (2504 > 2500), lowering kernel.perf_event_max_sample_rate to 79800
Aug 02 17:37:46 zik6242 kernel: perf: interrupt took too long (3131 > 3130), lowering kernel.perf_event_max_sample_rate to 63600
Aug 02 17:41:01 zik6242 kernel: perf: interrupt took too long (3920 > 3913), lowering kernel.perf_event_max_sample_rate to 51000
Aug 02 17:41:42 zik6242 systemd[1]: Starting Cleanup of Temporary Directories...
Aug 02 17:41:43 zik6242 systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully.
Aug 02 17:41:43 zik6242 systemd[1]: Finished Cleanup of Temporary Directories.
Aug 02 17:41:43 zik6242 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Aug 02 17:41:43 zik6242 kernel: audit: type=1130 audit(1627918903.020:78): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Aug 02 17:41:43 zik6242 kernel: audit: type=1131 audit(1627918903.020:79): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Aug 02 17:41:43 zik6242 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

I am on intel N3700 I have tried everything bout i915 etc... I don't think the problem comes from that. Indeed, I have no issue when I run in the standard kernel.

cellofellow commented on 2021-05-10 05:50 (UTC)

What would it take to enable the non-GPL build flag so that zfs-dkms works?

Ralf_Mardorf commented on 2021-02-20 08:08 (UTC)

dvzrv commented on 2020-09-03 19:03:

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

I had no time to do so and still don't have got the time. However, I keep it in mind. Yesterday I build 2 longterm kernels that only differ by CONFIG_HZ [1]. If I should do any testing, I'll report back. Don't reckon that this will happen soon, if at all. I just want to inform, that it's still on a todo list, it's just not that important to me.

Has got anybody who is using USB devices, excepted of habys, noticed a difference?

$ pacman -Qi linux-rt-cornflower linux-rt | grep -eNa -eVe -eDes -eBu
Name            : linux-rt-cornflower
Version         : 4.19.173_rt72-0.300
Description     : The Linux RT kernel and modules - CONFIG_HZ=300
Build Date      : Fri 19 Feb 2021 04:50:01 CET
Name            : linux-rt
Version         : 4.19.173_rt72-0.1000
Description     : The Linux RT kernel and modules - CONFIG_HZ=1000
Build Date      : Fri 19 Feb 2021 04:52:16 CET

rvalles commented on 2021-02-08 17:09 (UTC) seems alright.

dvzrv commented on 2021-02-06 16:35 (UTC)

@rvalles, @blackhole: Yes, I am also experiencing issues. I have already found the culprit in the config and will release a fixed version and rebuild for glibc 2.33 later today.

blackhole commented on 2021-02-06 15:56 (UTC) (edited on 2021-02-06 15:57 (UTC) by blackhole)

I have also big problems with latest linux-rt:

Error messages at boot about udev that cannot initialize socket, after it will go to recovery console but keyboard is not working.

Tested in 2 different computers and 2 different USB keyboard

linux-rt-lts is working fine and also archlinux last kernel

These systems are fully updated to today.

rvalles commented on 2021-02-04 19:24 (UTC) (edited on 2021-02-04 19:26 (UTC) by rvalles)

Latest PKGBUILD,, not working so well. 5.10.8 worked fine.

USB keyboard not working, lvm partitions not found in the LUKS container. Same results with fallback initrd. This is on a Thinkpad x395.

Mainline "linux" package (5.10.12-arch1-1 installed about the same time) is fine, so I discard mkinitcpio as culprit.

Herve_R commented on 2021-01-21 22:05 (UTC)

Could you add the patch from:

Without it, nvidia nv50 cards are freezing frequently (see bugreport I'm using it for few days now and it solved my problems.


as3ii commented on 2021-01-15 17:35 (UTC)

why clone the linux-rt repository which weighs 1.6GiB instead of just downloading the 176MiB source in .tar.gz format? This would save storage and cpu (during the git deltas resolution)

dvzrv commented on 2021-01-12 21:52 (UTC)

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)!

kflak commented on 2020-12-25 16:00 (UTC) (edited on 2020-12-26 06:41 (UTC) by kflak)

Getting the same error as @cavilory on an Asus TUF A15. EDIT: sorry for the noise, seems it was caused by a buggy sd card reader.

cavilory commented on 2020-12-03 06:43 (UTC) (edited on 2020-12-03 06:48 (UTC) by cavilory)

linux-rt 5.9.1-rt20-1-rt

Dmesg output:

BUG: using smp_processor_id() in preemptible [00000000] code: usb-storage/257
BUG: using smp_processor_id() in preemptible [00000000] code: usb-storage/252

on laptop Asus FX503

blackhole commented on 2020-12-01 13:27 (UTC)

Same bug reported in gentoo forum:

This is a serious bug, systems slow down, CPU load increase.

I have received this report: "...these errors happen on a AMD B450-f motherboard and a NUC7I7DNBE. The first uses the USB 3.0 controller onboard the processor chip, the second the USB controller on the Intel SOC..."

Yesterday I tested a Lenovo Yoga 530 with AMD Ryzen™ 7-2700U and the problem is confirmed.

linux-rt-lts not affected, so I switched to this one.

blackhole commented on 2020-12-01 08:10 (UTC) (edited on 2020-12-01 08:11 (UTC) by blackhole)

With the last realtime kernel, booting from USB I have this error:

[ 169.847376] BUG: using smp_processor_id() in preemptible [00000000] code: usb-storage/249

The error is repeating.

This is not present in mainline kernel.

Some suggestions?

kyak commented on 2020-11-05 10:31 (UTC)

@dvzrv Please see my comment below. Would you accept this simple change?

PKGBUILD now fetches the latest tarball from your gitlab repo instead of pulling the whole git history.

kyak commented on 2020-11-05 10:20 (UTC)

0001-ZEN-Add-sysctl-and-CONFIG-to-disallow-unprivileged-C.patch is not used in this package and should be removed from repo.

nixit commented on 2020-10-29 18:44 (UTC) (edited on 2020-10-29 18:47 (UTC) by nixit)


thanx, I tried that and still got some GPG errors when trying to add/import the key. $ gpg --auto-key-locate wkd --search-keys gpg: error searching keyserver: General error gpg: keyserver search failed: General error

hope for formatting turns out, I'm still trying to figure out how to put the error in a highlight like you did.

kyak commented on 2020-10-29 13:45 (UTC) (edited on 2020-10-29 13:48 (UTC) by kyak)

@dvzrv thanks a lot for maintaining this package! I'm considering switching to repository, but for now building it from source.

Previously, PKGBUILD would just fetch the kernel tarball. Now, it's using git to fetch sources from

Is it possible to ask PKGBUILD not to fetch the whole git history? I think it is not needed for makepkg. It will save huge amount of bandwidth and disk.

Maybe something like git clone --depth=1?

P.S. Maybe I need to clarify my use case a bit. I'm not keeping the build artifacts, including sources, once the build has finished (building it in tmpfs). So I will not gain speedup you might expect if you keep build directory between different releases.

dvzrv commented on 2020-10-28 21:30 (UTC)

@nixit: That key is in the archlinux-keyring package.

If you want to retrieve it for your own user you can do gpg --auto-key-locate wkd --search-keys

nixit commented on 2020-10-28 19:27 (UTC) (edited on 2020-10-28 19:28 (UTC) by nixit)

when I try to update, I get the following:

:: PGP keys need importing: -> C7E7849466FE2358343588377258734B41C31549, required by: linux-rt (linux-rt->headers linux-rt) ==> Import? [Y/n] y :: Importing keys with gpg... gpg: keyserver receive failed: No name problem importing keys"

any idea what is going on?

jempe commented on 2020-10-22 11:05 (UTC)

@dvzrv I will do that for the new vm Thanks @jhernberg Very usefull thanks

dvzrv commented on 2020-10-21 21:47 (UTC)

@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 (UTC)

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

jempe commented on 2020-10-21 20:38 (UTC)

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

dvzrv commented on 2020-10-21 15:50 (UTC)

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, 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 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC) (edited on 2020-07-19 15:01 (UTC) by Ralf_Mardorf)

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 (UTC)

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 (UTC) (edited on 2020-06-25 00:12 (UTC) by Marc.2377)

@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.

habys commented on 2020-05-15 00:16 (UTC) (edited on 2020-05-15 00:20 (UTC) by habys)

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 (UTC)

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 (UTC) (edited on 2020-03-21 08:30 (UTC) by Ralf_Mardorf)

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 (UTC)

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 (UTC) (edited on 2020-03-14 17:46 (UTC) by Ralf_Mardorf)

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 (UTC)

Where does the kernel go once it's compiled?

kflak commented on 2020-02-15 06:56 (UTC)

@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 (UTC)

@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 (UTC) (edited on 2020-02-14 17:10 (UTC) by jt525)

@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 (UTC)

@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 (UTC) (edited on 2020-02-14 12:49 (UTC) by dvzrv)

@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 (UTC)

I can't upgrade to because my DKMS modules won't install. Version installs just fine. Is there a substantial difference between the two versions, or can I just stay on 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/

Any help would be appreciated. Thanks!

kflak commented on 2020-02-13 18:42 (UTC)

@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 (UTC)

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

kflak commented on 2020-02-13 16:10 (UTC)

@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 (UTC)

@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 ;-) ).

kflak commented on 2020-02-12 17:35 (UTC)

@Alvo: efi=runtime kernel parameter seems to do the trick. Thanks a lot!

Alvo commented on 2020-02-12 14:35 (UTC)

@kflak Try adding efi=runtime to your kernel parameters.

kflak commented on 2020-02-12 11:01 (UTC)

@dvzrv: same story on linx-rt-lts. No efivars available there either.

kflak commented on 2020-02-12 10:54 (UTC)

@dvzrv: Thanks! I'll check the linux-rt-lts as well and see if this works.

dvzrv commented on 2020-02-12 10:49 (UTC)

@kflak: That's an odd one for sure. I'll try to reproduce this and get back to you!

kflak commented on 2020-02-12 10:45 (UTC)

@dvzrv: I marked it as solved because I accomplished my firmware upgrade objective by using the vanilla kernel. I'm using the prebuilt binary. Huge thanks for that, by the way! My glibc version is 2.31-1, linux-rt 5.4.17-rt9-2-rt

dvzrv commented on 2020-02-12 10:25 (UTC)

@kflak: Hm, I don't see why this wouldn't work. The config is the same as the config for the linux package in [core] in that regard (although there are other differences, which I'll look into in the coming weeks).

Did you rebuild this package for or did you install it from the unofficial repository in that version? If you're still on, but have glibc 2.31 there might be breakage and you should rebuild/upgrade.

Also, why do you mark the topic as [SOLVED], if it isn't solved?

kflak commented on 2020-02-12 08:58 (UTC)

linux-rt is not able to mount efivarfs on my system. With the vanilla kernel this works fine. Any pointers? For more details, check my post on the forum:

Alvo commented on 2020-01-03 22:37 (UTC)

I can't get it to work even with nvidia-dkms as the only dkms. I'm going to ask this question on the linux-rt-users.

aquilarubra commented on 2020-01-03 06:04 (UTC)

I also had issues with nvidia-dkms, with a previous kernel. Then, I don't know how they disappeared. It might be the latest kernel. Or it might be that I replaced it with nvidia, upgraded the kernel, then replaced nvidia with nvidia-dkms again just to test once more, and it was working. Check also if you have other dkms modules, which might interfere and hide the real problem.

Alvo commented on 2020-01-03 03:57 (UTC)

@dvzrv Thanks for the info I was able to boot into linux-rt without problem! I still get error when I run startx to start my window manager. The error I saw in demsg was "NVRM: failed to copy vbios to memory". I'm using nvidia-dkms and it's working fine with linux-ck-ivybridge. I wonder if you have experienced such issue before. Thanks in advance!

aquilarubra commented on 2019-12-30 21:59 (UTC)

Tried, but same result. Core dump, and disks not recognized. I will live with virtualbox only in a linux kernel. It's a pity, because I was running VST plugins in Windows, routed to Linux. I don't plan to change virtualbox, as I carry an external disk with the virtualbox images wherever I go. I see that there are many issues with virtualbox, so perhaps they will be fixed somewhen. But at the moment, linux-rt is the only kernel having these issues.

dvzrv commented on 2019-12-30 16:53 (UTC)

Also, sorry, I forgot to push the changes for ;-) It is up now. Enjoy.

dvzrv commented on 2019-12-30 16:50 (UTC)

@aquilarubra: I don't use virtualbox, sorry. There seems to be an issue with it on current vanilla kernel as well (and this is not the first time DKMS for it breaks). If you can switch, I would suggest looking into KVM/QEMU to have less of a pain with the out-of-tree modules.

In regards to the topic of older kernels, they are all still there:

Note, that due to the way mkinitcpio and all kernel packages were changed, you might have to remove vmlinuz images in /boot before downgrading (depending on how far back you go).

dvzrv commented on 2019-12-30 16:44 (UTC)

@Alvo: Please make sure to read the news on the main website. There was an item about this.

Alvo commented on 2019-12-30 03:28 (UTC)

Hello, I have trouble generating vmlinuz for this kernel. There was no vmlinuz generated after installation and there is no preset for this kerenl while running mkinitcpio. Can someone help me with this problem?

aquilarubra commented on 2019-12-29 20:58 (UTC)

Thanks for answers. I didn't have the time to try again, but I will give it a shot again. It was a pain to go back to AMD, after so many years. I experienced issues of any kind, but now that I solved each of them one by one, the result is impressive - compared to Intel, where I wasn't able to solve everything. Being my machine new, I don't have the older kernels. I'm not sure how to get them. But it's just fine to experiment with the 5.4.3 kernel. You mentioned 5.4.5... any new update?

Ralf_Mardorf commented on 2019-12-26 14:00 (UTC) (edited on 2019-12-26 14:04 (UTC) by Ralf_Mardorf)

Hi aquilarubra, I just want to let you know that virtualbox seems not to work on an Intel machine, when booted into "my" 5.4.5_rt3, but it works when booted into 5.4.6.arch3-1. Sorry, there's no time for further investigations. Regards, Ralf

Ralf_Mardorf commented on 2019-12-26 08:19 (UTC) (edited on 2019-12-26 08:57 (UTC) by Ralf_Mardorf)

Hi aquilarubra, first of all, I migrated from AMD CPUs with ATI and NVIDIA graphics to an Intel CPU with an Intel GPU, to get rid of issues with linux-rt, as well as audio and MIDI issues in general. I already experienced all kinds of trouble with AMD CPUs, ATI and NVIDIA graphics years before Ryzen 3000 was released. I can't comment on 5.4.3-rt1, but I build 5.4.5-rt3 and it works without issues, at least dkms did build modules for the AUR package virtualbox-bin 6.1.0-1, it boots and runs with all disks detected and without crashing. The kernel was build with some differences to the AUR package. I did not apply any other patch, but the rt patch only. I used the same config, but disabled AppArmor and Auditing support with menuconfig and while this doesn't affect functionality, for the sake of completeness PKGBUILD does use pkgver="${_pkgver}_rt${_rtpatchver}" instead of pkgver="${_pkgver}.${_rtpatchver}" and echo "${pkgbase#linux-rt}" > localversion.20-pkgname instead of echo "${pkgbase#linux}" > localversion.20-pkgname . You need to take a look at the log files. Does a 5.2 kernel work for you or at least a 4.19 kernel? I didn't experience issues with any of the listed kernels.

$ pacman -Q linux{,-rt{,-pussytoes,-cornflower,-securityink}}|cut -d\  -f2
$ echo $(uname -srvm;zgrep CONFIG_AUDIT\  /proc/config.gz)
Linux 5.4.5-rt3-0 #1 SMP PREEMPT_RT @1577303715 x86_64 # CONFIG_AUDIT is not set

Consider to write to linux-rt-users. Regards, Ralf

PS: FWIW did you try to load and unload the vbox modules on demand, instead of doing this at startup?

modprobe -av $(ls /lib/modules/$(uname -r)/kernel/misc/ | cut -d. -f1)
modprobe -rv $(ls -r /lib/modules/$(uname -r)/kernel/misc/ | cut -d. -f1)

It requires some modification, if there should be other modules, than just the vbox* modules in misc/, too.

aquilarubra commented on 2019-12-26 06:13 (UTC)

Any idea why it doesn't work (crashes at boot, doesn't recognize disks, etc.) with virtualbox-host-dkms?

aquilarubra commented on 2019-12-21 11:03 (UTC)

Now it's working with nvidia-dkms

aquilarubra commented on 2019-12-20 07:23 (UTC)

I tested the kernel again, once removing both of my 2 dkms modules (nvidia and virtualbox), once with only the nvidia dkms, and once with only the virtualbox dkms. The result is that, every time there is a dkms module, the kernel will hang at boot with a stack trace. So, there are definitely issues with dkms modules in general.

aquilarubra commented on 2019-12-19 20:58 (UTC)

I could narrow down the issue, in my case. If I remove nvidia-dkms, the kernel works, but nouveau is buggy and I get a garbled screen, which tends to end up in a loop. If I have nvidia-dkms, I get the stack trace. There are lines saying that preemption was disabled. So, they are apparently incompatible.

aquilarubra commented on 2019-12-17 21:46 (UTC)

I cannot boot this kernel with the Ryzen 3000 either. I added the unofficial repository and no luck. Compiled the kernel myself, it could load just once (I really cannot figure out how it worked once), then no more. The first message I always see is: /sys/firmware/efi/efivars: unknown filesystem type 'efivars' Then, I get a sort of stack trace. Every time it hangs at a different place, but it never completes the boot process. I call the rt kernel the same way of the default arch kernel, prepending amd-ucode: initrd /boot/amd-ucode.img /boot/initramfs-linux-rt.img I wonder if it must be compiled with some other options for AMD.

dvzrv commented on 2019-11-01 13:54 (UTC)

Please note, that there have been substantial changes to how mkinitcpio (>=27) works with vmlinuz images to create initramfs images. This change is reflected in the PKGBUILD for in alignment with all vanilla kernels in the main repositories.

dvzrv commented on 2019-10-08 07:49 (UTC)

@daniel712: Please be more specific than "cannot boot".

daniel712 commented on 2019-10-07 20:51 (UTC) (edited on 2019-10-08 09:02 (UTC) by daniel712)

I cannot boot this kernel on Ryzen 1700 (zen). Do i have to configure which CPU before the build (like during linux-ck build)?

During startup i get only houndreds of errors where normally the green OK Messages are. I did a standard makepkg -rsi after the git clone. During the build of the linux-ck kernel i have been asked to confirm the Type of the CPU (zen, zen2, etc pp). Do i have to configure this before the build?

dvzrv commented on 2019-10-06 15:19 (UTC)

@vlas: linux-rt has to be rebuilt because of a recent toolchain update (gcc, glibc, etc.). I'm releasing a new version, once it has finished building.

Ralf_Mardorf commented on 2019-10-06 15:08 (UTC) (edited on 2019-10-06 15:14 (UTC) by Ralf_Mardorf)

vlas, to stay as close as possible to upstream, consider to build by just using the rt-patch, but without the additional patches. IOW comment out line 30 and 31 of the PKGBUILD and the corresponding checksums, lines 49 and 50, then add a close bracket at the end of line 48. Subscribe to linux-rt-users to send a request to this mailing list. If possible add short log snippets or links against full log files. The ArchWiki could help regarding troubleshooting and log files.

vlas commented on 2019-10-06 14:22 (UTC)

Hello! I have difficulties with starting my system on linux-rt kernel. There are some photos and videos: Such problems happening for about half of a year, but now system is just not booting. Native linux package is OK, using it now. If you need more information, please let me know. System is up to date, linux-rt-headers is installed.

jhernberg commented on 2019-09-12 17:55 (UTC)

@m8D2: No, I saw that on the kernel mailing list, but think I've seen it mentioned in other places too. Maybe google will find some references.

Linus pulled a change to the kernel config file which indicates that he accepted it, and that the process has started, no clue when it will be finished. But I also know this from other communications with kernel developers.

Somehow I don't think you're alone being interest in seeing the patch set finally added to mainline :)

m8D2 commented on 2019-09-11 22:42 (UTC)

@jhernberg do you happen to have a source? I'm very interested in seeing rt patch getting to the main/lts kernels. Thanks!

jhernberg commented on 2019-08-19 07:43 (UTC)

In fact lately the process started to bring the rt patchset into the main kernel, so hopefully in the not too distant future it will just be another config option and no longer a set of out of tree patches.

Det commented on 2019-08-18 16:40 (UTC)

Great to see RT still around after reading "The future of RT-Linux?" question in

Ralf_Mardorf commented on 2019-07-28 10:16 (UTC)

There's a thread at the Jack-Devel mailing list, that is interesting regarding Spectre mitigations and CONFIG_AUDIT, see advice on xruns. The subscriber is able to reduce frames/period from 24 to 12, take a look at this posting.

dvzrv commented on 2019-06-18 22:02 (UTC)

@microsoftenator: you're absolutely right! same goes for linux-rt-lts (had a false positive when grepping for BCACHE). Please forget what I wrote earlier! :)

microsoftenator commented on 2019-06-18 08:34 (UTC)

@dvzrv I'm pretty sure bcache is disabled for rt kernels

dvzrv commented on 2019-06-17 22:36 (UTC)

Please also note, that the current TCP based vulnerability in all kernels probably won't be patched in linux-rt, until it is ported to 5.1.x (as 5.0.x is EOL).

merlyn commented on 2019-06-11 18:18 (UTC) (edited on 2019-06-25 13:29 (UTC) by merlyn)

5.0.19_rt is working for me. @Ralf thanks for the tip. @jhernberg and @dvzrv thanks for your work maintaining and packaging this!

jhernberg commented on 2019-05-17 08:39 (UTC)

@merlyn: Yes, reporting your issue on the linux-rt-users mailing list is probably the best recourse!

Ralf_Mardorf commented on 2019-05-16 15:39 (UTC)

merlyn, you should subscribe to the linux-rt-users discussion and bug reporting mailing list

merlyn commented on 2019-05-16 15:21 (UTC)

I tried 5.0.10_rt and I'm still getting the same error.

dvzrv commented on 2019-05-13 21:17 (UTC) (edited on 2019-05-14 13:37 (UTC) by dvzrv)

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

You can add it to your pacman.conf with:

Server =$arch

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


tallero commented on 2019-04-23 23:01 (UTC)

Solved using gpg --recv-keys <missing key>

tallero commented on 2019-04-23 22:55 (UTC)

GPG keys are not known

==> Verifying source file signatures with gpg... linux-5.0.7.tar ... FAILED (unknown public key 38DBBDC86092693E) patch-5.0.7-rt5.patch ... FAILED (unknown public key 05641F175712FA5B) ==> ERROR: One or more PGP signatures could not be verified!

Ralf_Mardorf commented on 2019-04-18 18:39 (UTC)

Here the result of an USB stress test. To connect all the devices I had to replace some long USB cables by short USB cables. For my machine it was a power stress test. At the end of the test I unplugged my keyboard from the PS/2 port and connected it to an USB port. For more than an hour all USB devices stay connected, excepted of the keyboard that was connected a few minutes ago.

[rocketmouse@archlinux ~]$ uname -a
Linux archlinux 5.0.7-rt5-1-rt #1 SMP PREEMPT RT Tue Apr 16 14:50:10 CEST 2019 x86_64 GNU/Linux
[rocketmouse@archlinux ~]$ date; lsmod | grep hci; lsusb; lsusb | wc -l
Thu Apr 18 19:07:24 CEST 2019
ahci                   40960  5
libahci                40960  1 ahci
xhci_pci               20480  0
libata                278528  2 libahci,ahci
ehci_pci               20480  0
xhci_hcd              262144  1 xhci_pci
ehci_hcd               94208  1 ehci_pci
Bus 002 Device 002: ID 8087:8000 Intel Corp. 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 003: ID 174c:1153 ASMedia Technology Inc. ASM1153 SATA 3Gb/s bridge
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 022: ID 1235:8201 Focusrite-Novation 
Bus 003 Device 033: ID 0930:6544 Toshiba Corp. TransMemory-Mini / Kingston DataTraveler 2.0 Stick
Bus 003 Device 008: ID 056d:4001 EIZO Corp. 
Bus 003 Device 006: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 003 Device 004: ID 0451:8044 Texas Instruments, Inc. 
Bus 003 Device 023: ID 174c:1153 ASMedia Technology Inc. ASM1153 SATA 3Gb/s bridge
Bus 003 Device 020: ID 0582:0127 Roland Corp. GR-55
Bus 003 Device 031: ID 8644:8003 Intenso GmbG Micro Line
Bus 003 Device 032: ID 1307:0165 Transcend Information, Inc. 2GB/4GB/8GB Flash Drive
Bus 003 Device 015: ID 0944:010f KORG, Inc. nanoKONTROL studio controller
Bus 003 Device 014: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 003 Device 030: ID 05ac:12ab Apple, Inc. iPad 4/Mini1
Bus 003 Device 021: ID 1058:1021 Western Digital Technologies, Inc. Elements Desktop (WDBAAU)
Bus 003 Device 029: ID 05ac:129f Apple, Inc. iPad 2
Bus 003 Device 028: ID 1acc:1735 Midiplus Co, Ltd. 
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[rocketmouse@archlinux ~]$ date; lsusb; lsusb | wc -l 
Thu Apr 18 20:24:49 CEST 2019
Bus 002 Device 002: ID 8087:8000 Intel Corp. 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 003: ID 174c:1153 ASMedia Technology Inc. ASM1153 SATA 3Gb/s bridge
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 022: ID 1235:8201 Focusrite-Novation 
Bus 003 Device 033: ID 0930:6544 Toshiba Corp. TransMemory-Mini / Kingston DataTraveler 2.0 Stick
Bus 003 Device 008: ID 056d:4001 EIZO Corp. 
Bus 003 Device 006: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 003 Device 004: ID 0451:8044 Texas Instruments, Inc. 
Bus 003 Device 023: ID 174c:1153 ASMedia Technology Inc. ASM1153 SATA 3Gb/s bridge
Bus 003 Device 020: ID 0582:0127 Roland Corp. GR-55
Bus 003 Device 031: ID 8644:8003 Intenso GmbG Micro Line
Bus 003 Device 032: ID 1307:0165 Transcend Information, Inc. 2GB/4GB/8GB Flash Drive
Bus 003 Device 015: ID 0944:010f KORG, Inc. nanoKONTROL studio controller
Bus 003 Device 014: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 003 Device 030: ID 05ac:12ab Apple, Inc. iPad 4/Mini1
Bus 003 Device 021: ID 1058:1021 Western Digital Technologies, Inc. Elements Desktop (WDBAAU)
Bus 003 Device 029: ID 05ac:129f Apple, Inc. iPad 2
Bus 003 Device 034: ID 04d9:1702 Holtek Semiconductor, Inc. Keyboard LKS02
Bus 003 Device 028: ID 1acc:1735 Midiplus Co, Ltd. 
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

So far no issue at all. Almost all of the devices were not used, they were just connected.

merlyn commented on 2019-04-18 13:30 (UTC)

Apr 18 02:20:16 SiriusC kernel: ohci-pci 0000:00:12.1: frame counter not updating; disabled
Apr 18 02:20:16 SiriusC kernel: ohci-pci 0000:00:12.1: HC died; cleaning up
Apr 18 02:20:16 SiriusC kernel: usb 4-1: USB disconnect, device number 2
Apr 18 02:20:16 SiriusC kernel: usb 4-3: USB disconnect, device number 3

This was with 5.0.7 rt

rvalles commented on 2019-04-18 13:15 (UTC)

@merlyn: OHCI, unlike UHCI, is unusual. This explains why linux-rt users aren't complaining in droves.

merlyn commented on 2019-04-18 13:11 (UTC)

Thanks for looking into this. There was an error related to OHCI. I'll find the entry in my journal and post it.

jhernberg commented on 2019-04-17 17:45 (UTC)

@merlyn: Would there be something in the dmesg output?

jhernberg commented on 2019-04-17 17:44 (UTC)

Ralf I'm sorry, but I'm not sure I understood all that :)

Still I take it that you have no problem with USB devices?

Ralf_Mardorf commented on 2019-04-16 15:56 (UTC)

I forgot to mention that the USB mouse works with all kernels, so at least one USB device always works. At the moment I'm using 5.0.7_rt5-1 build from the original AUR tarball, with the same config and patches.

Ralf_Mardorf commented on 2019-04-16 12:40 (UTC)

I build all 5.x-rt kernels without the nf_tables-fix patch and using another config. I'm just doing this because of an issue that happened when running 5.0.3_rt1-1 from AUR and since I didn't use the patch and another config for 5.0.3_rt1-0, a kernel build before 5.0.3_rt1-1 was provided by the AUR. I don't know what actually was the culprit for the issue I experienced.

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

I didn't use 5.0.7.arch1-1 and 5.0.7_rt4-0 with an USB device. All other kernels were used with an USB device, but not with an USB audio device.

Date: Thu, 28 Mar 2019 From: Ralf To: linux-rt-users Subject: Re: firefix core dump with linux 5.0.3_rt1-2

On Thu, 28 Mar 2019 10:29:54 +0100, Bernhard Landauer wrote:

The following happens only with Manjaro's rt patched version of linux50. No issue with the regular version.

When firefox tries to recover tabs of a previous session, they crash. Normal operation of firefox is not affected. Only these specific tabs are broken.

Full journal with core dump here:


does Manjaro use additional patches, maybe those used by linux-rt from AUR?

I build 5.0.3_rt1-0 without the nf_tables-fix patch and using a different config than linux-rt from AUR.

Apart from the name 5.0.3_rt1-1 is equal with linux-rt from AUR.

I needed to downgrade, because a windows guest in virtualbox became unresponsive. I tried several times to use the guest, when booted into the AUR kernel 5.0.3_rt1-1. There is no issue when using 5.0.3_rt1-0 without one patch and a different config.

[rocketmouse@archlinux ~]$ grep pussytoes\ /var/log/pacman.log | grep downgrade [2019-03-27 06:33] [ALPM] downgraded linux-rt-pussytoes (5.0.3_rt1-1 -> 5.0.3_rt1-0)

Regards, Ralf

jhernberg commented on 2019-04-16 11:55 (UTC)

@merlyn, I'll try to reproduce when I get some time. Something specific I ought to be looking for? Anyone else have problems with USB devices?

Ralf_Mardorf commented on 2019-04-16 07:54 (UTC) (edited on 2019-04-16 07:58 (UTC) by Ralf_Mardorf)

Just a heads-up, if somebody wants to build 5.0.7-rt4, do it without htmldocs.

merlyn commented on 2019-04-11 14:14 (UTC)

My USB devices keep disconnecting. This has happened with RT 5.0.3 and 5.0.5. I'm now on the stock 5.0.7 kernel and there seems to be no problem. Neither is there a problem with rt-lts 4.19.31

dvzrv commented on 2019-03-23 00:07 (UTC)

@patrickelectric: Did you try to build using makepkg -A?

patrickelectric commented on 2019-03-21 14:09 (UTC)

Is it possible to add arch armv7h ?

jhernberg commented on 2019-03-03 09:44 (UTC)

I've just removed the patch for nvidia that has been used for years. Apparently it's no longer needed, have tested on 2 systems one with the current nvidia driver, and another with nvidia-340xx. The symptom was that without the patch X would hang making the GUI unresponsive, while the rest of the system kept on working. Hopefully it doesn't break anything :)

jhernberg commented on 2019-01-11 10:18 (UTC)

A heads up. As there is no 4.19.13 in the arch kernel git repo, I've made this script download tarballs instead. This will also mean that it will require less diskspace to build, but a larger download for each patch.

yoant commented on 2019-01-10 00:06 (UTC)

@jhernberg: that was that (running out of diskspace), thank you and sorry for the noise. (By the way, thanks for this package!)

jhernberg commented on 2019-01-09 10:59 (UTC)

@yoant: IIRC I updated the git repo from the older version and I just tried to build it from scratch, no errors. Are you possibly running out of diskspace/ram? It needs a lot since the devs moved the archlinux kernel script to use a git repo mirroring the entire kernel tree.

yoant commented on 2019-01-09 03:43 (UTC)

Hello, I'm encountering an issue while building (while extracting sources):

==> Extracting sources...
  -> Creating working copy of archlinux-linux git repo...
fatal: 'v4.19.10-arch1' is not a commit and a branch 'makepkg' cannot be created from it
==> ERROR: Failure while creating working copy of archlinux-linux git repo

Does the build miss a git fetch to get the tag?

PS. I'm using git version 2.20.1

Ralf_Mardorf commented on 2018-12-14 11:17 (UTC)

Actually I'm building

$ makepkg -s 
==> Making package: linux-rt-securityink 4.19.8_rt6-0 (Fri 14 Dec 2018 11:07:31 AM CET)

right now, so I didn't notice an issue related to the revoked subkey.

$ wget -q{xz,sign}
$ xz -cd patch-4.18.7-rt5.patch.xz | gpg --verify patch-4.18.7-rt5.patch.sign -
gpg: WARNING: This subkey has been revoked by its owner!
gpg: reason for revocation: Key is superseded
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 6425 4695 FFF0 AA44 66CC  19E6 7B96 E816 2A8C F5D1
     Subkey fingerprint: AC7B D081 0599 51BD 51AD  E800 4FE5 E326 2872 E4CC

Ok, if this makes 'makepkg -s" fail, then consider to remove "${_pkgver}-${_rtpatchver}.patch.sign" and the second 'SKIP' from the PKGBUILD.

goddisignz commented on 2018-12-14 10:16 (UTC) (edited on 2018-12-14 10:16 (UTC) by goddisignz)

Hi Ralf_Mardorf, I know the difference between "unknown public key" and "key has been REVOKED". Please read my comment more carefully.

I imported the key twice, first without the keyserver and then again from The second time it was not modified. I also removed and reimported it. Still revoked and still doesnt work...

Ralf_Mardorf commented on 2018-12-14 09:46 (UTC) (edited on 2018-12-14 09:49 (UTC) by Ralf_Mardorf)

On 2018-12-14 08:44 goddisignz wrote:

Hi, building the package currently fails because a signature has been revoked.

patch-4.18.7-rt5.patch ... FAILED (public key 4FE5E3262872E4CC has been revoked)

Folks, if you don't have the skills to use Arch Linux, then read the fine manual.

gpg --keyserver hkp:// --recv-keys 4FE5E3262872E4CC

jhernberg could you please pin one of the countless replies related to signatures?

goddisignz commented on 2018-12-14 08:44 (UTC)

Hi, building the package currently fails because a signature has been revoked.

patch-4.18.7-rt5.patch ... FAILED (public key 4FE5E3262872E4CC has been revoked)

goodboy commented on 2018-10-12 16:06 (UTC)

@Ralf_Mardorf heh, yes I found your comment shortly after submitting my useless one and solved the issue. linux-rt is now running like butter for my pro audio needs.

Next time I'll post back after figuring it out on my own, my bad. Thanks for follow up nonetheless!

Ralf_Mardorf commented on 2018-10-07 09:02 (UTC) (edited on 2018-10-07 09:10 (UTC) by Ralf_Mardorf)

goodboy, see my comment from 2018-08-30 07:23 in reply to CyrIng, if you would have searched a little bit, you would have found my comment from 2018-05-10 10:56 or any general hint related to this topic, provided by the Internet. There is nothing a maintainer needs to update. You need to import the missing keys.

$ gpg --keyserver hkp:// --recv-keys A5E9288C4FA415FA

Do the same for the other missing key.

goodboy commented on 2018-10-07 00:59 (UTC)

PGP check is failing:

==> Verifying source file signatures with gpg... archlinux-linux git repo ... FAILED (unknown public key A5E9288C4FA415FA) patch-4.18.7-rt5.patch ... FAILED (unknown public key 4FE5E3262872E4CC) ==> ERROR: One or more PGP signatures could not be verified!

Can we get an update?

solnce commented on 2018-09-30 19:16 (UTC) (edited on 2018-09-30 19:17 (UTC) by solnce)

@MrG0z: awesome!

@jhernberg: please include this in the PKGBUILD.

Cerdicipe commented on 2018-09-30 11:40 (UTC)

To avoid the git clone operation (and use much less disk space), you can use this patch:

Ralf_Mardorf commented on 2018-09-25 18:05 (UTC)

I build 4.18_rc8_rt1, 4.18.5_rt3 and 4.18.7_rt5 the way in a 3.9G tmpfs, if more than 8G are required to build it the way, I would be forced to build on a SSD instead of tmpfs, since I've got 8G of RAM.

jhernberg commented on 2018-09-25 17:06 (UTC)

Note, that you'll need more than 8GB of space to build this now. So if you have a 16GB machine and build on tmpfs, you'll need to give it more than the default 50% or RAM.

Ralf_Mardorf commented on 2018-08-30 07:23 (UTC) (edited on 2018-08-30 07:23 (UTC) by Ralf_Mardorf)

CyrIng, somewhere the comments of the last four month contain a reply regarding this "issue". I read comments until I found this reply and then I replied to your comment. Writing the reply to you, needed more time, than to search the other reply.

CyrIng commented on 2018-08-30 01:07 (UTC) (edited on 2018-08-30 01:07 (UTC) by CyrIng)

makepkg stops with: ==> Verifying source file signatures with gpg...
linux-4.16.tar ... FAILED (unknown public key 79BE3E4300411886)
patch-4.16.18 ... FAILED (unknown public key 38DBBDC86092693E)
patch-4.16.18-rt12.patch ... FAILED (unknown public key 4FE5E3262872E4CC)
==> ERROR: One or more PGP signatures could not be verified!

blackhole commented on 2018-08-29 22:06 (UTC)

Yes, there is not more the module and efi=runtime is working. Thanks

jhernberg commented on 2018-08-29 21:56 (UTC)

@blackhole: I don't think there is such a module. The /sys/firmware/efi/efivars/ issue seems to be a bug in the rt patch, but it gets populated if you add the efi=runtime boot flag.

kureta commented on 2018-08-25 20:02 (UTC)

I have updated my gcc to 8.2.0, then reinstalled linux-rt with "clean-build" option using yay.It should have been built using gcc 8.2.0 but I've got this error anyway when I tried to dkms install nvidia/396.54 -k 4.16.18-rt12-1-rt. So I've set IGNORE_CC_MISMATCH=1 to install it anyway.

jhernberg commented on 2018-08-25 11:02 (UTC) (edited on 2018-08-25 11:04 (UTC) by jhernberg)

No don't change anything in the kernel config. The error msg says that your kernel is built with 8.1.1, did you reinstall it before building linux-rt again?

If you use devtools, there ought to be no problem at all, no matter what you have installed on your local system, that's exactly the reason to use devtools..

kureta commented on 2018-08-25 10:56 (UTC)

@jhernberg: build just finished and it gave the same error while automatically installing nvidia-dkms.

Compiler version check failed:

The major and minor number of the compiler used to compile the kernel:
gcc version 8.1.1 20180531 (GCC)
does not match the compiler used here:
cc (GCC) 8.2.0

I have checked my gcc version. it is 8.2.0. Should I also clean build nvidia-dkms?

kureta commented on 2018-08-25 10:46 (UTC)

@jhernberg: Yes, I just realized that I should rebuild the kernel instead of downgrading gcc. You are right it should rebuild dkms modules during installation. I am currently rebuilding and it takes a long time. I am using yay. I actually interrupted the building process half way through to edit the PKGBUILD file and add -j8 argument and restarted the build. By the way, should I change anything in menuconfig? I saw those lines were commented out.

jhernberg commented on 2018-08-25 10:06 (UTC) (edited on 2018-08-25 10:14 (UTC) by jhernberg)

@kureta: No need for that, just rebuild the kernel, and when you install it again then nvidia-dkms will be run again. If for some reason that isn't easy with whatever aur helper you might be using, do this:

Get the buildscript with "cower -d linux-rt", then change to the linux-rt dir and run, "makepkg -cfi". Even better would be to install devtools, and then run "extra-x86_64-build" which will install and update a chroot with all dependencies installed and then run makepkg. When done install manually with "pacman -U".

To use all cpus for compiling, edit /etc/makepkg.conf and make sure that you have something like MAKEFLAGS="-j9".

@blackhole: I'll look into it.

kureta commented on 2018-08-25 09:06 (UTC) (edited on 2018-08-25 09:09 (UTC) by kureta)

For all those nvidia-dkms folks out there. I had similar problems and found the reason to be gcc updates in-between linux-rt and nvidia-dkms updates. My specific problem was that linux-rt was compiled using gcc 8.1.1 and later gcc was updated to 8.2.0. Now if nvidia-dkms is updated it gives an error stating there is a version mismatch between the compiler used to compile the rt kernel and the current compiler. It is easy to miss the error during a system update.

What I did was to downgrade gcc and run sudo dkms autoinstall. You can find the specific gcc versions here: /var/lib/dkms/nvidia/<YOUR NVIDIA_DKMS VERSION>/build/make.log.

Currently I am trying to reinstall linux-rt with clean build and use the latest gcc without downgrading. It seems like a better solution but I didn't want to do that because compiling the kernel takes a very long time. I guess it does not use all cores.

blackhole commented on 2018-08-11 21:24 (UTC)

I just checked it. Really efivars is enabled in configuration, but /sys/firmware/efi/efivars/ is empty, since the corresponding kernel module is missing.

colinjmatt commented on 2018-08-06 18:35 (UTC)

I'm currently getting the error "mount: unknown filesystem type 'efivar(f)s'" at boot after grub, but the system appears to boot correctly after that message. This message does not appear when using grub to boot the default Arch Linux kernel. Any ideas what's causing this?

jhernberg commented on 2018-08-01 19:42 (UTC) (edited on 2018-08-01 19:43 (UTC) by jhernberg)

@teetest I have linux-headers 4.17.10-1 installed, that's not a problem.

What does your Xorg log say?

I suppose you have nvidia-utils installed, do you have a /usr/lib/nvidia/xorg/

teetest commented on 2018-07-31 23:21 (UTC) (edited on 2018-08-01 12:36 (UTC) by teetest)

@jhernberg Thank you for your information. I use Nvidia Optimus. Default kernel "Linux" worked.

In journalctl log, it shows "(EE) NVIDIA(0): Failed to initialize the GLX module".

Then i found out package "nvidia-dkms 396.45-2" require "linux-headers>=4.17".

So i downgrade kernel and nvidia-dkms. But it still shows "(EE) NVIDIA(0): Failed to initialize the GLX module".

I don't know why.

Nvidia 1050ti

Nvidia Optimus

nvidia-dkms 396.45-2 / nvidia-dkms 396.24-7

-------A PART OF ERRORS---------

jhernberg commented on 2018-07-29 12:39 (UTC)

@teetest: What errors do you see, have you been able to use it before?

I just updated the kernel to 4.16.18-rt11, it installs and builds. It also has no problem to build/install nvidia-dkms. I boot my system using the builtin Intel GPU, but do use the nvidia occasionally together with bumblebee. This appears to work fine, the module is loaded and for instance primusrun glxsperes64 runs without any problems.

Ralf_Mardorf commented on 2018-07-29 09:01 (UTC) (edited on 2018-07-29 09:15 (UTC) by Ralf_Mardorf)

I'm using an Intel graphics. However, take a look at the right upper side 'Required by' packages. There are links to nvidia-340xx-rt and nvidia-rt. The '(make)' behind nvidia-340xx-rt is confusing, actually linux-rt{,-headers} are listed as makedepends of the nvidia packages, so it's unlikely that the nvidia packages are optional makedepends of linux-rt. Take a look at the nvidia PKGBUILD's makedepends regarding ">=" and "<". Please report back with detailed information, it might be helpful for other users of the proprietary nvidia driver.

teetest commented on 2018-07-29 06:08 (UTC)

I can't boot in linux-rt kernel with nvidia-dkms. Anyone else?

oberon2007 commented on 2018-05-23 21:59 (UTC)

@blackhole, those warning are not really a problem. To get rid of them these patches can be added:

blackhole commented on 2018-05-23 14:30 (UTC)

I have a lot of "sibling call from callable instruction with modified stack frame" compiling.

Ralf_Mardorf commented on 2018-05-13 02:25 (UTC) (edited on 2018-05-13 02:40 (UTC) by Ralf_Mardorf)

to7m also consider to read NO_HZ: Reducing Scheduling-Clock Ticks, Counting on the time stamp counter and The high-resolution timer API. The latter two timer related articles are outdated, but lead into the right direction. Also keep in mind that by default rtc is not getting high priority by rtirq.

$ grep rtc /etc/rtirq.conf.pacnew 
# RTIRQ_NAME_LIST="rtc snd usb i8042" # old

to7m commented on 2018-05-12 22:57 (UTC) The CONFIG_HZ options are currently unaltered (set to 300), but according to this page should be set to 1000 if I understand correctly :)

sharddin commented on 2018-05-10 20:36 (UTC)

I apologize, but it happened that unpacking and compilation passed without "extra" manipulation of the keys ... It started with: makepkg -sri --skipchecksums --skippgpcheck ...

Ralf_Mardorf commented on 2018-05-10 10:56 (UTC) (edited on 2018-05-10 11:13 (UTC) by Ralf_Mardorf)

On 2018-05-10 10:22, sharddin commented:

bsd-unpacking error. Keys verification errors (unknow keys)

sharddin, if you need help, write complete sentences. Too funny, at the moment there's a thread regarding checksums vs signing at Arch general. Take a look at the PKGBUILD's "validpgpkeys" section. From command line e.g. run

$ gpg --keyserver hkp:// --recv-keys ABAF11C65A2970B130ABE3C479BE3E4300411886

Why do you build from AUR without reading the wiki?

Btw. I used the current PKGBUILD, it builds without issues.

$ uname -rm
4.16.7-rt1-1-rt x86_64

sharddin commented on 2018-05-10 10:22 (UTC)

bsd-unpacking error. Keys verification errors (unknow keys)

jhernberg commented on 2018-05-04 20:09 (UTC)

FWIW, I've updated the script for 4.16-rt already, I normally run it for a while before I push it, especially when it's such a version jump. Will bump the package if there are no problems..

I made it CONFIG_NO_HZ_IDLE though..

rvalles commented on 2018-05-04 17:47 (UTC) (edited on 2018-05-04 17:47 (UTC) by rvalles)

@Ralf_Mardorf: It's odd arch's main kernel did that. Not much to say until we hear from them on this topic.

Re: announcement, it wasn't meant to bother the maintainers (who surely know about releases immediately), but rather sharing on the happiness; I've had a Vega64 for around a month, in which I had to suffer through 4.15+ requirement, with no -rt. I definitely wish the realtime team well on their effort to get PREEMPT_RT mainlined.

Ralf_Mardorf commented on 2018-05-04 17:09 (UTC) (edited on 2018-05-04 17:16 (UTC) by Ralf_Mardorf)

The maintainer is subscribed to linux-rt-users and most likely didn't miss the announcement. You might have noticed his request.

The config provided by his current tarball is equal to mine.

$ uname -r; zgrep CONFIG_NO_HZ /proc/config.gz 
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set

rvalles, what's your opinion on that?

rvalles commented on 2018-05-04 08:10 (UTC)

4.16 patches available.

jhernberg commented on 2018-02-07 19:14 (UTC)

@scimmia: Thanks !:) Just a coincidence, but here is a recent quote from one of the rt patch developers on the mailing list regarding applying the rt patch to an unintended kernel version.

"I'd be careful about this. There's a few (not many) subtle changes that get backported to stable that can break RT. You wont be able to notice it with compiling, but it can cause deadlocks in certain scenarios."

jhernberg commented on 2018-02-07 19:09 (UTC)

Yes, as gcc got updated nvidia aborts the module building. This is a good thing as you could otherwise experience subtle bugs. I've bumped the pkgver so that you guys rebuild the kernel, after that nvidia will build again.

blackhole commented on 2018-02-06 23:26 (UTC)

check gcc version

UlrichH commented on 2018-02-06 22:21 (UTC)

New weird thing,nvidia-dkms fail to build with 4.14.15-rt13-1-rt

Scimmia commented on 2018-02-05 21:15 (UTC)

Alright then. Most patches aren't as extensive as these and will apply to all kernels within a feature release. If it doesn't work here, it doesn't work.

jhernberg commented on 2018-02-05 18:48 (UTC)

@Scimmia: Not without merge conflicts, sometimes many this time only 1.

I realize that many Archlinux users want the latest and greatest, but afaik things have never been done like that with the rt patchset. I am not going to start fixing merge conflicts in the kernel for the rt patch. It's a far too important piece of software for my limited understanding of the kernel insides and rt specifics. I draw the limit at trying to add important back ported security fixes if I'm aware of them. If you look at Gentoo, you'll see that they do the same.

Of course feel free to adopt and to bring to community :)

Scimmia commented on 2018-02-05 16:23 (UTC)

And that patch doesn't apply to 4.14.17?

jhernberg commented on 2018-02-05 09:29 (UTC)

@Scimmia: This kernel is also still up to date, see:

jhernberg commented on 2018-01-31 13:10 (UTC)

For whoever flagged it out of date due to 4.15 being out, it always takes a while before the patchset is ported to a new kernel... In this case there is however a new patch to bring this kernel to 4.14.15-rt13, will upload that when I've tested it a bit.

jhernberg commented on 2018-01-29 12:32 (UTC)

@UlrichH: Hmm, this sounds like a thorny issue... Not sure have time to spend playing with alsa loopback device again..:) But apart from some difference in difference in kernel config I'm hard pressed to imagine what the difference could be... I find it hard to believe that just the BFQ patch would change much in this context, especially regarding sample rate conversion... How about linux-rt-lts, is that better? What might help is if you could track down when it started happening, is it something new in this last kernel release, etc.

But in the end very hard to make a diagnosis at distance...

UlrichH commented on 2018-01-27 23:44 (UTC)

@jhernberg I just diffed it, I don't see anything weird. There is the bfq / cfq diff... I don't which one can really make a difference regarding this module :/

jhernberg commented on 2018-01-26 13:00 (UTC)

@UlrichH: I really have no idea about that... Sound strange indeed. Any big differences in the kernel config file?

UlrichH commented on 2018-01-26 09:54 (UTC) (edited on 2018-01-26 09:54 (UTC) by UlrichH)

I'm using snd-aloop, and it seems broken using linux-rt - working fine with linux-rt-bfq. It sounds like it's not on the correct samplerate, but only switching kernel makes it ok. What information would you need to investigate ?

Gimmeapill commented on 2018-01-13 10:28 (UTC)

Same here: all good so far, actually better results with cyclictest than the firsts 4.14.

rvalles commented on 2018-01-11 19:31 (UTC) (edited on 2018-01-11 19:32 (UTC) by rvalles)

@jhernberg. Yeah, my new microcode is dated 2017-11-20, suggesting Intel has had it ready for a while. The good news is that, after running and using it for a few hours together with cycletest running, there doesn't seem to be any degradation to the max latency column compared to the pre-meltdown-workaround kernel.

jhernberg commented on 2018-01-11 18:59 (UTC) (edited on 2018-01-11 19:00 (UTC) by jhernberg)

@rvalles: You are welcome! I had it built 24 hours earlier :), but normally test run it a little before I upload a new script. It has turned up a few issues, and there is no testing on the AUR..

There was an intel ucode update too, so hopefully we are a bit safer now..

rvalles commented on 2018-01-11 17:41 (UTC)

Thank you for the prompt update.

jhernberg commented on 2018-01-07 21:55 (UTC)

Regarding Meltdown, since I'm not a kernel developer I prefer to wait for an official rt patch for a Meltdown patched kernel, rather than blindly applying patches without the necessary understanding. A new patch will be available in a few days.

rvalles commented on 2018-01-07 21:13 (UTC)

Grand. Unflagged until news. Had already read the LWN article before it blew up. It does unfortunately look terrible for latency, particularly when using linux-rt on the desktop (e.g. running web browsers) where disabling the mitigation isn't sensible.

Ralf_Mardorf commented on 2018-01-07 20:54 (UTC) (edited on 2018-01-07 21:00 (UTC) by Ralf_Mardorf)

4.14.8-rt9 is the latest version available, see, hence the package is not out of date. Vulnerabilities such as don't render a package out of date. There are no fixes yet, see and also consider to read

rvalles commented on 2018-01-07 20:39 (UTC)

@Ralf_Mardorf: Neither server or DAW are my use case. My use case is the desktop. Linux-rt makes Linux tolerable. I have never said I can't wait and I can't tell how you came to believe so. Please elaborate on why you think flagging a package that's out of date as such is an abuse of the package action.

Ralf_Mardorf commented on 2018-01-07 20:12 (UTC)

The comments aren't for discussions, hence I posted to Arch proaudio. I care about reasonable security. I also care about the comments from jhernberg, the maintainer who mentioned that he has burnt out on packaging, so asking to backport a patch set, that likely is counter-productive in a real-time context, doesn't make much sense. Is linux-rt a suitable kernel for your server farm? Is KPTI required to increase security of your DAW? Is the possible loss of performance caused by KPTI tolerable for your DAW? Is there a reason for you, that you can't wait until upstream backported the patch set, to the long-term stable kernels?

Btw. that you flagged the package out-of-date is an abuse of the package action.

rvalles commented on 2018-01-07 19:16 (UTC)


Good for you that you don't care about security in your use case.

To answer your question, posted to proaudio instead of here for some reason, we is the rest of us.

Ralf_Mardorf commented on 2018-01-07 11:55 (UTC) (edited on 2018-01-07 11:58 (UTC) by Ralf_Mardorf)

I replied to rvalles' meltdown comment by posting to Arch proaudio

rvalles commented on 2018-01-07 08:08 (UTC)

We need a meltdown update. (i.e. based on 4.14.12)

jhernberg commented on 2017-12-22 12:38 (UTC)

@smoge: How about your problems, still there?

jhernberg commented on 2017-12-22 12:37 (UTC)

@Ralf_Mardorf: Thanks for clearing that up.

kflak commented on 2017-12-22 08:27 (UTC)

@jhernberg: Thanks for clearing that up!

Ralf_Mardorf commented on 2017-12-22 08:26 (UTC)

It is an upstream issue that building virtualbox modules doesn't work for kernels 4.14 with virtualbox < 5.2.2. Upgrading virtualbox to 5.2.2 does solve the issue, at least when using

jhernberg commented on 2017-12-22 08:11 (UTC)

@Ralf_Mardorf: How is it with vbox modules on this new kernel? Any other issues with it?

@kflak: I don't use yaourt at all, but I'd imagine that yaourt linux-rt is sufficient. You seem to build the packages 3 times on purpose ;) That said I think I've seen comments of yaourt running out of ram building the kernel for some users. Best way to build packages in general is really extra-x86_64-build and then to install using makepkg -U package-tarball. This also insures that all optional dependencies are present when you build, otherwise you might end up with some missing functionality.

Ralf_Mardorf commented on 2017-12-22 08:05 (UTC) (edited on 2017-12-22 08:05 (UTC) by Ralf_Mardorf)

With or without an AUR helper, you only need to build the package linux-rt, to automatically build the headers and docs packages, too.

kflak commented on 2017-12-22 08:00 (UTC)

@jhernberg & @dvzrv: I'm using yaourt to build the kernel, haven't yet been plumbing the depths of doing this manually... I run yaourt linux-rt linux-rt-headers linux-rt-docs. Would it then be sufficient to run only one of these commands, say fx yaourt linux-rt-headers to build both the kernel and the headers?

Ralf_Mardorf commented on 2017-12-22 05:36 (UTC) (edited on 2017-12-22 05:37 (UTC) by Ralf_Mardorf)

I posted that much, including jackd messages, in reply to smoge's requests. However, I mentioned to continue at, but since we now have got an audio mailing list again, I recommend to join Btw. I posted my results of cyclictest to the mailinglist, see

jhernberg commented on 2017-12-22 00:32 (UTC)

@Gimmeapill: Well I've also had that impression, another reason that I've been reluctant to upgrade it, but it was getting impossible to sit on it so long..;)

But keep in mind that the -rt version is really the experimental branch of the rt patchset. I plan to upgrade linux-rt-lts to 4.9-rt once I know that there are no big issues with this kernel. That is still a rock solid kernel AFAIK, and possibly the one most people should to use. That is a LTS release of the kernel and a stable version of the rt patchset.

@kflak: I also wonder what you use to build with, because that's certainly not normal.. Maybe you get confused because it's a split package and it creates 3 different packages.

My recommendation would be to install devtools, and use the extra-x86_64-build script to build the kernel. Follow dvzrv instructions, but replace the makepkg command with extra-x86_64-build which will create a chroot, install all needed dependencies and finally build the packages. That is how most TUs and devs build the distro packages.

@dvzrv: That would be a stone off my chest and great for the community!

dvzrv commented on 2017-12-21 22:02 (UTC) (edited on 2017-12-21 22:05 (UTC) by dvzrv)

@jhernberg: Thanks so much! We'll hopefully see to it, that this kernel can be included in [community] one day!

@kflak: How are you building? With

  git clone 
  cd linux-rt 
  makepkg -L 

this should do fine.

kflak commented on 2017-12-21 21:25 (UTC)

Newbie question here, I preemptively apologize for my stupidity...: When I install the kernel the whole build process runs three times, once for linux-rt, once for linux-rt-headers and once for linux-rt-docs. However, it seems that it is pretty much the same thing happening all three times. Am I crazy, or is there a way of reducing the build time to only once, and still get all the headers/docs installed?

Gimmeapill commented on 2017-12-21 09:10 (UTC) (edited on 2017-12-21 09:12 (UTC) by Gimmeapill)

@jhernberg: I forgot to mention that with the stock kernel I get around 35 micro secs worst case scenario. So yes, there is still a very tangible benefit with the RT patch.

Regarding the perf degradation across versions of the RT kernel: I could also empirically notice more xruns with 4.14 RT than 4.11 RT, as I always run at the limits.

It could be the RT patch being not very mature yet for this version, or the kernel itself (which seems to have grown significantly bigger). I'll try to rebuild with localmodconfig see if that helps (although in theory it shouldn't).

jhernberg commented on 2017-12-21 07:45 (UTC)

@Gimmeapill: Thanks! It's good to know that the work is appreciated!

Regarding the cyclictest results, I've had the same impression. I guess this is due to the kernel or patch itself, on the other hand a difference of 12us vs 15us doesn't really seem like it would be a huge problem ;) This is already very respectable results compare to other kernels.

Gimmeapill commented on 2017-12-20 22:17 (UTC) (edited on 2017-12-20 22:18 (UTC) by Gimmeapill)

@jhernberg: Thanks a lot for your work during all this years, the burnout is quite understandable.

I just hope you won't drop the towel completely ;-)

Anyway I gave 4.14 a very brief test, and performance seems to be a bit worse than 4.11. (which was itself a bit worse than 4.9).

More specifically: 'cyclictest -S -m -p98' with governor in performance mode shows on my system a max latency of 15 micro secs with 4.14.6-rt7-1-rt, vs 13 micro secs with 4.11.12-rt14-1-rt, vs 12 micro secs with 4.9.40-rt30-1-rt

On the good news: no stability issue so far.

jhernberg commented on 2017-12-20 16:28 (UTC)

@Ralf_Mardorf: Please restrain your pastes in the comments, as reading the comments is really getting a little bit difficult with everything you have pasted. For instance there really is no need to paste the output of jack starting up, this is not a mailing list where one can just move on to the next message...

jhernberg commented on 2017-12-20 16:02 (UTC)

Hello everyone,

Sorry that I've been missing in action and have neglected my packages. I haven't had much time at all due to real life and other engagements. In fact I've come to realize that I've burnt out on packaging... I think I've found someone to take over this and some other packages, so hopefully things will be a lot better in the future!

I just updated this package to the latest upstream version, in fact due to a lot changing in Archlinux upstream, this is more or less a new package. I'm not on my normal machine to test it, so not 100% sure that everything is running at it's best, but I think everything is ok. Please give it a good test and let me know about any issues.

Ralf_Mardorf commented on 2017-12-03 06:02 (UTC) (edited on 2017-12-03 06:11 (UTC) by Ralf_Mardorf)

Hi, I didn't update to 4.14.3-rt5 since building vbox modules failed for 4.14 from testing as well as for the local build of 4.14-rt1. $ pacman -Q linux{,-rt{,-cornflower,-pussytoes}}|awk '{print $2}' 4.14-2 4.13.13_rt5-1 4.11.12_rt16-1 4.14_rt1-1 I booted [rocketmouse@archlinux ~]$ uname -r 4.13.13-rt5-1-rt Regards, Ralf PS: I neither upgraded to 4.14.3-1, the current version available by testing.

timofonic commented on 2017-12-02 22:26 (UTC)

What about 4.14?

smoge commented on 2017-10-28 19:05 (UTC)

I can't use my Bluetooth mouse (logitech mx master) with 4.13.10_rt3. I'll try to find more details.

Ralf_Mardorf commented on 2017-10-27 19:58 (UTC) (edited on 2017-10-28 09:39 (UTC) by Ralf_Mardorf)

Hi smoge, if you should have questions regarding 4.13.7_rt1-1 or one of the RT kernels currently installed on my machine, send a request to $ pacman -Q linux{,-rt{,-pussytoes,-cornflower}} linux 4.13.9-1 linux-rt 4.13.10_rt3-1 linux-rt-pussytoes 4.11.12_rt15-2 linux-rt-cornflower 4.11.12_rt16-1

smoge commented on 2017-10-24 20:24 (UTC)

Ralf_Mardorf, how 4.13 is working for you?

Ralf_Mardorf commented on 2017-10-19 07:29 (UTC)

$ uname -rm 4.13.7-rt1-1-rt x86_64 $ diff -r /usr/src/linux-rt /tmp/linux-rt diff -r /usr/src/linux-rt/PKGBUILD /tmp/linux-rt/PKGBUILD 8,12c8,12 < #pkgbase=linux # Build stock -ARCH kernel < pkgbase=linux-rt # Build kernel with a different name < _srcname=linux-4.13 < _pkgver=4.13.7 < _rtpatchver=rt1 --- > #pkgbase=linux # Build stock -ARCH kernel > pkgbase=linux-rt # Build kernel with a different name > _srcname=linux-4.11 > _pkgver=4.11.12 > _rtpatchver=rt14 24,25c24,25 < "${_pkgver}-${_rtpatchver}.patch.xz" < "${_pkgver}-${_rtpatchver}.patch.sign" --- > "${_pkgver}-${_rtpatchver}.patch.xz" > "${_pkgver}-${_rtpatchver}.patch.sign" 29c29 < "90-${pkgbase}.hook" --- > '90-linux-rt.hook' 31c31 < "${pkgbase}.preset" --- > 'linux-rt.preset' 33,35c33 < sha256sums=('SKIP' < 'SKIP' < 'SKIP' --- > sha256sums=('b67ecafd0a42b3383bf4d82f0850cbff92a7e72a215a6d02f42ddbafcf42a7d6' 36a35 > '707c5f18dfb795761b0b7ac6f946f03774f9f99317306fd54d8724d17d9c7729' 37a37 > '0ba8106cea3808d40966ba687df844e83f966a5daf4d4d9b527c2932b8eb007e' 79c79 < sed -i "s|CONFIG_LOCALVERSION=.*|CONFIG_LOCALVERSION=\"-${pkgrel}${_kernelname}\"|g" ./.config --- > sed -i "s|CONFIG_LOCALVERSION=.*|CONFIG_LOCALVERSION=\"${_kernelname}\"|g" ./.config 97c97 < make oldconfig # using old config from previous kernel version --- > #make oldconfig # using old config from previous kernel version 208,209c208,209 < #install -D -m644 Documentation/DocBook/Makefile \ < # "${pkgdir}/usr/lib/modules/${_kernver}/build/Documentation/DocBook/Makefile" --- > install -D -m644 Documentation/DocBook/Makefile \ > "${pkgdir}/usr/lib/modules/${_kernver}/build/Documentation/DocBook/Makefile" 304c304 < #rm -f "${pkgdir}/usr/lib/modules/${_kernver}/build/Documentation/DocBook/Makefile" --- > rm -f "${pkgdir}/usr/lib/modules/${_kernver}/build/Documentation/DocBook/Makefile" Only in /tmp/linux-rt: .SRCINFO

Ralf_Mardorf commented on 2017-10-18 18:13 (UTC)

[rocketmouse@archlinux ~]$ uname -rm 4.11.12-rt16-1-rt-cornflower x86_64 [rocketmouse@archlinux ~]$ jackd -dalsa -dhw:HDSPMx579bcc -r44100 -p128 -n2 [snip] JACK server starting in realtime mode with priority 10 self-connect-mode is "Don't restrict self connect requests" creating alsa driver ... hw:HDSPMx579bcc|hw:HDSPMx579bcc|128|2|44100|0|0|nomon|swmeter|-|32bit configuring for 44100Hz, period = 128 frames (2.9 ms), buffer = 2 periods ALSA: final selected sample format for capture: 32bit integer little-endian ALSA: use 128 periods for capture ALSA: final selected sample format for playback: 32bit integer little-endian ALSA: use 128 periods for playback FWIW building the package for 4.13.7-rt1 failed with "install: cannot stat 'Documentation/Doc/Book/Makefile': No such..." "A failure occurt in package_linux-rt-headers:(). ...", obviously line 207, 208, 209 and 304 of the PKGBUILD are obsolet. The Nvidia patch could be still applied and IIRC oldconfig only requires to push enter all the times, assuming you don't want some new RME and a few new ALSA things. I build 4.11.12-rt16 and tried to build 4.13.7-rt1 in the morning, in a hurry, before I needed to go to work.

smoge commented on 2017-10-18 05:09 (UTC)

I will test again with rt16. I just uninstalled rt15, I did not have the time to investigate the problem.

Ralf_Mardorf commented on 2017-10-18 03:37 (UTC) (edited on 2017-10-18 03:38 (UTC) by Ralf_Mardorf)

What error messages do you get? Please, lets continue at . Jack does run on my machine. $ uname -rm 4.11.12-rt15-rt-pussytoes x86_64 $ pacman -Q jack2 jack2 1.9.10.r293.gc44a220f-1 $ jackd -dalsa -dhw:HDSPMx579bcc -r44100 -p128 -n2 [snip] JACK server starting in realtime mode with priority 10 self-connect-mode is "Don't restrict self connect requests" creating alsa driver ... hw:HDSPMx579bcc|hw:HDSPMx579bcc|128|2|44100|0|0|nomon|swmeter|-|32bit configuring for 44100Hz, period = 128 frames (2.9 ms), buffer = 2 periods ALSA: final selected sample format for capture: 32bit integer little-endian ALSA: use 128 periods for capture ALSA: final selected sample format for playback: 32bit integer little-endian ALSA: use 128 periods for playback Btw. 4.11.12-rt16 and 4.13.7-rt1 were released.

smoge commented on 2017-10-17 19:20 (UTC)

I could not start jack with 4.11.12-rt15 and went back to rt14. Is it a known problem?

Ralf_Mardorf commented on 2017-10-14 08:03 (UTC) (edited on 2017-10-14 08:08 (UTC) by Ralf_Mardorf)

I didn't rebuild the linux-rt package, but obviously the culprit is that sed -i "s|CONFIG_LOCALVERSION=.*|CONFIG_LOCALVERSION=\"${_kernelname}\"|g" ./.config previously was sed -i "s|CONFIG_LOCALVERSION=.*|CONFIG_LOCALVERSION=\"-${pkgrel}${_kernelname}\"|g" ./.config Regarding the dkms issue I added a comment to .

Ralf_Mardorf commented on 2017-10-13 06:07 (UTC)

Sorry for misusing the comments like a support forum. I just did this, since we don't have an active audio mailing list anymoere, let alone that the state of official audio packages is disgusting, see . I at least build Ardour and Jack myself, e.g. $ pacman -Q jack2 jack2 1.9.10.r293.gc44a220f-1 Back to the topic, on my machine even linux-rt 4.11.12_rt14-1 was build from the linux-rt 4.11.12_rt13-1 tarball, so as soon as I've got time again, I'll take a closer look at the AUR's linux-rt diffs. FWIW I just thought that I didn't run into the dkms issue when building older kernels, e.g $ pacman -Q linux-rt{,-cornflower,-pussytoes} linux-rt 4.11.12_rt14-1 linux-rt-cornflower 4.11.12_rt13-1 linux-rt-pussytoes 4.11.12_rt15-2 The PACKAGE_VERSION dkms.conf error also appears, if I reinstall linux-4.13.5-1, anyway, I still wonder why /lib/modules/ contains 4.11.12-rt15-rt-pussytoes instead of 4.11.12-rt15-2-rt-pussytoes or 4.11.12-2-rt15-rt-pussytoes. Regarding 'grep -i dkms /var/log/pacman.log' the dkms issue is related to virtualbox-bin 5.1.28 and not to the kernel packages, since there wasn't this issue for the previous virtualbox-bin 5.1.26. So regarding this issue everything is good and I seemingly need to fix the PACKAGE_VERSION issue by fixing another package. My line of thinking why the kernel packages have something to do with the virtualbox file seemingly is wrong, I just didn't recognize the error message before. My apologies, I'll stop spamming the comments.

Ralf_Mardorf commented on 2017-10-12 22:28 (UTC)

Hi, I'm still missing something. [rocketmouse@archlinux aur]$ ls /lib/modules/ 4.11.12-1-rt14-rt 4.11.12-rt15-rt-pussytoes extramodules-4.11-rt extramodules-4.11-rt-pussytoes 4.11.12-rt13-1-rt-cornflower 4.13.5-1-ARCH extramodules-4.11-rt-cornflower extramodules-4.13-ARCH [rocketmouse@archlinux aur]$ ls linux-rt-pussytoes-* linux-rt-pussytoes-4.11.12_rt15-2-x86_64.pkg.tar.xz linux-rt-pussytoes-docs-4.11.12_rt15-2-x86_64.pkg.tar.xz linux-rt-pussytoes-headers-4.11.12_rt15-2-x86_64.pkg.tar.xz [rocketmouse@archlinux aur]$ ls /lib/modules/4.11.12-rt15-rt-pussytoes/kernel/misc vboxdrv.ko vboxnetadp.ko vboxnetflt.ko vboxpci.ko The package release is missing, but the modules were build. Regards, Ralf $ diff linux-rt linux-rt-pussytoes Only in linux-rt: 90-linux-rt.hook Only in linux-rt-pussytoes: 90-linux-rt-pussytoes.hook Only in linux-rt: linux-rt.install Only in linux-rt: linux-rt.preset Only in linux-rt-pussytoes: linux-rt-pussytoes.install Only in linux-rt-pussytoes: linux-rt-pussytoes.preset diff linux-rt/PKGBUILD linux-rt-pussytoes/PKGBUILD 8,9c8,9 < #pkgbase=linux # Build stock -ARCH kernel < pkgbase=linux-rt # Build kernel with a different name --- > #pkgbase=linux # Build stock -ARCH kernel > pkgbase=linux-rt-pussytoes # Build kernel with a different name 12c12 < _rtpatchver=rt14 --- > _rtpatchver=rt15 14c14 < pkgrel=1 --- > pkgrel=2 29c29 < '90-linux-rt.hook' --- > "90-${pkgbase}.hook" 31c31 < 'linux-rt.preset' --- > "${pkgbase}.preset" 37c37 < '0ba8106cea3808d40966ba687df844e83f966a5daf4d4d9b527c2932b8eb007e' --- > 'SKIP' 97c97 < #make oldconfig # using old config from previous kernel version --- > make oldconfig # using old config from previous kernel version Only in linux-rt: .SRCINFO ################################################################################################ :: Running post-transaction hooks... (1/3) Install DKMS modules ==> dkms install virtualbox/bin -k 4.11.12-rt15-rt-pussytoes dkms.conf: Error! No 'PACKAGE_VERSION' directive specified. Error! Bad conf file. File: /usr/src/virtualbox-bin/dkms.conf does not represent a valid dkms.conf file. ==> dkms install vboxhost/5.1.28 -k 4.11.12-rt15-rt-pussytoes [snip] [root@archlinux aur]# grep hook /usr/src/linux-rt-pussytoes/PKGBUILD # pacman hook for initramfs regeneration "90-${pkgbase}.hook" # install pacman hook for initramfs regeneration sed "s|%PKGBASE%|${pkgbase}|g" "${srcdir}/90-${pkgbase}.hook" | install -D -m644 /dev/stdin "${pkgdir}/usr/share/libalpm/hooks/90-${pkgbase}.hook" [root@archlinux aur]# pacman -Ql linux-rt-pussytoes | grep hook linux-rt-pussytoes /usr/share/libalpm/hooks/ linux-rt-pussytoes /usr/share/libalpm/hooks/90-linux-rt-pussytoes.hook [root@archlinux aur]# grep -v \# /usr/src/virtualbox-bin/dkms.conf PACKAGE_NAME="vboxhost" PACKAGE_VERSION= AUTOINSTALL=yes BUILT_MODULE_NAME[0]="vboxdrv" BUILT_MODULE_LOCATION[0]="vboxdrv" DEST_MODULE_LOCATION[0]="/kernel/misc" BUILT_MODULE_NAME[1]="vboxnetflt" BUILT_MODULE_LOCATION[1]="vboxnetflt" DEST_MODULE_LOCATION[1]="/kernel/misc" BUILT_MODULE_NAME[2]="vboxnetadp" BUILT_MODULE_LOCATION[2]="vboxnetadp" DEST_MODULE_LOCATION[2]="/kernel/misc" BUILT_MODULE_NAME[3]="vboxpci" BUILT_MODULE_LOCATION[3]="vboxpci" DEST_MODULE_LOCATION[3]="/kernel/misc"

Ralf_Mardorf commented on 2017-10-12 07:47 (UTC)

Hi Joakim, the changes made to the tarball make it a hassle to edit it for building a customized kernel ;). Before going to work I tried to do it in a hurry. ##### After editing ##### $ diff /tmp/aur/linux-rt /usr/src/linux-rt-pussytoes Only in /tmp/aur/linux-rt: linux-rt.install Only in /tmp/aur/linux-rt: linux-rt.preset Only in /usr/src/linux-rt-pussytoes: linux-rt-pussytoes.install Only in /usr/src/linux-rt-pussytoes: linux-rt-pussytoes.preset diff /tmp/aur/linux-rt/PKGBUILD /usr/src/linux-rt-pussytoes/PKGBUILD 8,9c8,9 < #pkgbase=linux # Build stock -ARCH kernel < pkgbase=linux-rt # Build kernel with a different name --- > #pkgbase=linux # Build stock -ARCH kernel > pkgbase=linux-rt-pussytoes # Build kernel with a different name 12c12 < _rtpatchver=rt14 --- > _rtpatchver=rt15 31c31 < 'linux-rt.preset' --- > "${pkgbase}.preset" 37c37 < '0ba8106cea3808d40966ba687df844e83f966a5daf4d4d9b527c2932b8eb007e' --- > 'SKIP' 97c97 < #make oldconfig # using old config from previous kernel version --- > make oldconfig # using old config from previous kernel version ##### I ended up with ##### ==> dkms install virtualbox/bin -k 4.11.12-rt15-rt-pussytoes dkms.conf: Error! No 'PACKAGE_VERSION' directive specified. Error! Bad conf file. File: /usr/src/virtualbox-bin/dkms.conf does not represent a valid dkms.conf file. :D Accidently I build in /usr/src instead of doing it in a copy in /tmp, as I do usually, however, this shouldn't be the culprit. For old tarballs ${pkgbase}.preset was the default, fortunately this is unmissable, while the dkms issue is easy to miss. I've got no time to fix it now, since I need to go to work. Next time you update linux-rt, it would be nice, if you could return to the style of older tarballs. This time I'll fix it myself, as soon as I've got time to do so. Regards, Ralf

Gimmeapill commented on 2017-09-12 07:07 (UTC)

@jhernberg: Some perf issues here, I had to rollback to 4.9.x. I didn't confirm with cyclictest (yet), but I had problems with audio applications GUI responsiveness and stability on my Intel based Ivy bridge notebook. Nothing outstanding in regards to xruns though.

vee commented on 2017-09-10 01:00 (UTC)

@jhernberg thank you for the update to `4.11`. Did you notice too many warnings during build on this particular version. Didn't really notice this during `4.9` build.

jhernberg commented on 2017-09-09 16:04 (UTC) (edited on 2017-09-09 16:05 (UTC) by jhernberg)

@blackhole: I normally run this: "cyclictest -S -m -p98". I suppose it's possible it got fixed in the last patch, or that it's hardware dependent (driver/module). For the time being I'm using a laptop that always had higher max values, so hard to test.

blackhole commented on 2017-09-07 21:40 (UTC)

Just tested here. I don't see differences from the previous kernel. My test is with tuna and CPU governor set to performance. cyclictest -t1 -n -p99 -i100 -o10 -v | oscilloscope -s1000 >/dev/null I have a max value of 11us and most of time between 1-3 us Maybe your test is different from mine. Also with a strong test like this hackbench -l $loop & cyclictest -l $loop -n -m -Sp98 -i100 -d0 I have these results: T: 0 (10268) P:98 I:100 C: 19747 Min: 1 Act: 1 Avg: 1 Max: 10 T: 1 (10335) P:98 I:100 C: 19723 Min: 1 Act: 4 Avg: 1 Max: 15 T: 2 (10411) P:98 I:100 C: 19695 Min: 1 Act: 2 Avg: 1 Max: 13 T: 3 (10461) P:98 I:100 C: 19669 Min: 1 Act: 2 Avg: 1 Max: 7 T: 4 (10529) P:98 I:100 C: 19648 Min: 1 Act: 2 Avg: 1 Max: 10 T: 5 (10605) P:98 I:100 C: 19622 Min: 1 Act: 2 Avg: 1 Max: 16 T: 6 (10606) P:98 I:100 C: 19600 Min: 1 Act: 2 Avg: 1 Max: 10 T: 7 (10607) P:98 I:100 C: 19576 Min: 1 Act: 3 Avg: 1 Max: 11

jhernberg commented on 2017-09-07 12:16 (UTC)

@RedTide: Did you try building and installing it with makepkg -cfi?

jhernberg commented on 2017-09-07 12:14 (UTC)

@dvzrv: Sorry for the late reply, real life gets in the way sometimes.. I haven't seen any problems like that, hopefully 4.11-rt fixes it for you..

redtide commented on 2017-08-24 05:46 (UTC)

I had the same problem as ToxicAvenger, no idea if it's a pamac fault, but after some time the build fails with a no available space on disk error, where the are 15GB available.

dvzrv commented on 2017-08-07 11:28 (UTC)

@jhernberg: I have a weird issue with the current xf86-video-intel on linux-rt. Whenever I do something graphical (starting certain applications), this happens: [ 71.210650] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun [ 71.211089] [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A [ 71.211142] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun and weird overlay glitches appear, that make me restart at some point, because they become to annoying. Let me know, when there's anything to test for 4.11-rt. I'd be happy to help (especially because this bug is making it hard to work with my x220 atm).

jhernberg commented on 2017-08-07 09:38 (UTC)

The solution to the nvidia kernel module build problem is to do something like this: make IGNORE_PREEMPT_RT_PRESENCE=1 SYSSRC=/usr/lib/modules/"${_kernver}/build" module I've asked a nvidia maintainer and the fix will be in nvidia-dkms-384.59-3, so hopefully we're back to trouble free installation soon!

Joermungand commented on 2017-08-05 10:46 (UTC)

@blackhole: The last of the four sanity checks, preempt_rt_sanity_check, line 173.

blackhole commented on 2017-08-05 08:56 (UTC)

@Joermungand What exactly did you remove in Kbuild?

jhernberg commented on 2017-08-04 10:45 (UTC)

I can confirm that NVIDIA again refuses to build on RT kernels :( It's due to a test that they added back, not quite sure what will be easiest way to build it now.

Joermungand commented on 2017-08-03 13:46 (UTC)

@blackhole: The reason it fails to install on the real-time kernel is the ‘Sanity checks of the build environment and target system/kernel’ in the Kbuild file in the driver’s source. It’s a dirty hack, but I got it to build and run perfectly fine by simply removing the offending sanity check and doing the dkms install manually on the kernel.

Joermungand commented on 2017-08-02 17:18 (UTC)

@blackhole: Nope; dkms build failed with the latest version.

blackhole commented on 2017-08-01 16:05 (UTC)

Did you succeed in installing latest nvidia? In the log: "The NVIDIA driver does not support real-time kernels..."

zappathustra commented on 2017-07-30 12:03 (UTC)

@jhernberg: Followed your advice and it worked perfectly. Thanks!

zappathustra commented on 2017-07-21 21:20 (UTC)

@jhernberg: Thank you, it seems quite simple indeed. I actually learned on the Arch forum that building package in a chroot is the right way to go, even though it's usually not needed. So it's not a bug if a package won't build in a normal environment. I'll let you know when I have time to do that.

jhernberg commented on 2017-07-15 13:17 (UTC) (edited on 2017-07-15 13:18 (UTC) by jhernberg)

@zappathustra: It's quite easy, you install the devtools package, and then instead of running makepkg (or others) to build the package, you run the extra-x86_64-build command in the dir containing the PKGBUILD. This will install all the needed dependencies in a chroot and then build the package.

zappathustra commented on 2017-07-15 10:37 (UTC)

@jhernberg: Not sure I want (nor know how) to do that; for the moment I'll ask on the Arch forum. If anything interesting emerges, I'll post here.

jhernberg commented on 2017-07-14 10:41 (UTC)

I still didn't have time to make a 4.11-rt, but will do when I get the time to build and test. Normally I skip the first few releases of the rt kernel to avoid problems, but it's getting time to do this.

jhernberg commented on 2017-07-14 10:31 (UTC)

@zappathustra: Sorry for the late answer, but just don't have enough time lately.. No idea about that error, but I find it strange that it builds on my machine and not on yours.. Maybe try to build it in a chroot using extra-x86_64-build from the devtools package?

zappathustra commented on 2017-07-06 20:01 (UTC) (edited on 2017-07-06 20:02 (UTC) by zappathustra)

Trying to compile today, but compilation dies with: kernel/watchdog_hld.c: Dans la fonction « watchdog_overflow_callback »: kernel/watchdog_hld.c:112:3: error: déclaration implicite de la fonction « printk_kill »; vouliez-vous utiliser « printk_emit » ? [-Werror=implicit-function-declaration] The French part means "implicit declaration of function "printk_kill"; did you mean "printk_emit"?" I could probably compile with -Wno-error so that warnings aren't considered errors, but maybe it's not wise?

ToxicAvenger commented on 2017-04-26 16:24 (UTC) (edited on 2017-04-26 16:26 (UTC) by ToxicAvenger)

Thanks jhernberg!! That worked beautifully! The system was actually trying to compile it on swap memory. But your command saved the installation! I actually made some tweakings in threadirq, cpufreq and noatime. Got a real music production machine now! :) (I'm using on a i5 machine) This kernel is a must-have for producers! Thank you guys!!

jhernberg commented on 2017-04-05 17:50 (UTC) (edited on 2017-04-05 17:51 (UTC) by jhernberg)

@ToxicAvenger: No need for threadirq. Cpufreq might depend on your hardware, fwiw I use pstate on my i7 cpus with no problem. No atime maybe on hdd, don't think it would matter at all on sdd. About grub I don't know, but make sure that it has an entry to boot the rt kernel. Regarding building, maybe try something like "makepkg -ci" in the PKGBUILD dir. This will build the package, clean up and finally install.

ToxicAvenger commented on 2017-04-05 14:13 (UTC)

Just got an error right in the end, in the "make" step. It says I don't have space available on the device: drivers/message/fusion/mptctl.ko: final close failed: Não há espaço disponível no dispositivo make[1]: *** [scripts/Makefile.modpost:125: drivers/message/fusion/mptctl.ko] Error 1 make: *** [Makefile:1123: modules] Error 2 How can I compile this kernel in other location? I used pamac in order to this, but pamac won't ask you for a specific location when compiling. Actually where is "drivers/message/fusion"?? I dont think this is in my HD. And my HD has lots of space, 460GB. How to solve this? Thanks in advance.

ToxicAvenger commented on 2017-04-05 12:56 (UTC)

Just a noob question: After installing the rt kernel, do I still need to: - Add threadirq parameter to kernel? - Set cpufreq to performance? - Add noatime to fstab? - Use the command "# grub-mkconfig -o /boot/grub/grub.cfg"? I'm guessing that I should edit grub files to make sure that the rt kernel is the default kernel to boot, but I dunno about these above.

jhernberg commented on 2017-03-01 23:11 (UTC)

The old ticker config of 1000Hz is obsolete :) Now days hrtimers offer a higher resolution than jiffies. I use i7 cpus, and for me the pstate driver works very well, but you can easily change the governor if you want to. If you want to, you can verify the kernel latencies on your system with cyclictest, and some hackbench, see:

sekret commented on 2017-03-01 11:31 (UTC)

May I ask why the timer frequency is set to 300Hz by default rather than 1000Hz? Also, wouldn't it be better to use the performance governor by default? Or in other words: Is this kernel supposed to be optimized to the highest level or some sort of compromise?

Gelmo commented on 2017-02-22 18:57 (UTC)

@davelis90 Take a look at this page:

davelis90 commented on 2017-02-22 08:00 (UTC) (edited on 2017-02-22 08:04 (UTC) by davelis90)

Hello! Could someone write the steps I need to follow (what to type in the command prompt) in order to download and install a realtime kernel in an Ubuntu system (version 16.02)? I am new in Linux and I have no idea how to do it, I only managed to download a low latency kernel but it shouldn´t be enough for my application. Thank you very much in advance.

jhernberg commented on 2017-02-16 17:42 (UTC)

FYI, nvidia-dkms ought to work again

jhernberg commented on 2017-02-07 13:40 (UTC) (edited on 2017-02-07 13:41 (UTC) by jhernberg)

@blackhole: I've asked the -rt devs and they seem fairly convinced that the problem lies in the vbox modules doing something that works on vanilla but breaks on realtime. They said that it's hard to tell what is going on due to Arch's low loglevel. They suggested to add the following to the kernel flags, to see if there would be better console output: "debug ignore_loglevel printk.devkmsg=off" The debug flag might be picked up by systemd though, thus the reason for "printk.devkmsg=off". They were unsure if systemd would spam the console anyways, but let's try it?

blackhole commented on 2017-02-07 10:18 (UTC)

I have installed to MSI H81M-E33 + i7-4770 with 6 usb ports connected. I am sure it is a timing problem, however. I have booted with blacklisted vbodrv modules, after I have loaded manually and no crash.

jhernberg commented on 2017-02-07 06:36 (UTC)

@blackhole: What kind of hardware do you have?

blackhole commented on 2017-02-06 21:12 (UTC)

Here the problem is that vbox modules are compiling just fine, but once loaded the boot process crash. This is not occurring all times. Maybe it is a question of loading order, I don't know. I think I will use a little script trick: I will blacklist them by default while loading the modules with Desktop environment autostart if the kernel is not realtime.

jhernberg commented on 2017-02-06 19:49 (UTC)

@blackhole: There is a discussion lower down about similar problems in the past, maybe helpful? Were the boot problems due to the vbox modules?

blackhole commented on 2017-02-06 18:18 (UTC)

Realtime kernel is incompatible with virtuabox modules... I have disabled all blacklist vboxpci blacklist vboxnetflt blacklist vboxnetadp blacklist vboxdrv and now boot is fine!

blackhole commented on 2017-02-06 16:36 (UTC)

I have a lot of errors and boot hangs See screenshots Standard kernel 4.9.x is booting fine on the same machine

jhernberg commented on 2017-02-06 13:39 (UTC)

4.9.6-rt4 is uploaded. I didn't have very much time to test it, so I sincerely hope there isn't anything that I missed. If so please excuse me, and please let me know ASAP!

jhernberg commented on 2017-01-31 12:45 (UTC)

I'm building 4.9-rt kernels and will upload the buildscript once I've tested them.

jhernberg commented on 2016-11-13 11:48 (UTC)

Please don't flag as out of date when it isn't..! There is no patch available for 4.8.7-rt, only for 4.8.6-rt. See:

jhernberg commented on 2016-11-13 11:46 (UTC)

@alcomatt: This is a pain, and not the first time it happens.. Not quite sure what the right fix is, would be better fixed upstream, rather than patched by us in either linux-rt or nvidia packages. I'll see what can be done.

alcomatt commented on 2016-11-07 22:50 (UTC)

Hah, dirty but works, thanks !

blackhole commented on 2016-11-07 22:18 (UTC) (edited on 2016-11-07 22:20 (UTC) by blackhole)

The "dirty" trick... Go to /var/lib/dkms/nvidia/375.10/source/nvidia-drm/ Substitute MIT with GPL in nvidia-drm-linux.c Recompile with dkms autoinstall -k 4.8.6_rt5-1-rt

alcomatt commented on 2016-11-07 22:06 (UTC) (edited on 2016-11-07 22:17 (UTC) by alcomatt)

nvidia-rt from AUR fails to build with this kernel. The error in make.log: d -r -o /var/lib/dkms/nvidia/375.10/build/nvidia-modeset/nv-modeset-interface.o /var/lib/dkms/nvidia/375.10/build/nvidia-modeset/nvidia-modeset-linux.o LD [M] /var/lib/dkms/nvidia/375.10/build/nvidia.o LD [M] /var/lib/dkms/nvidia/375.10/build/nvidia-modeset.o LD [M] /var/lib/dkms/nvidia/375.10/build/nvidia-drm.o LD [M] /var/lib/dkms/nvidia/375.10/build/nvidia-uvm.o Building modules, stage 2. MODPOST 4 modules FATAL: modpost: GPL-incompatible module nvidia-drm.ko uses GPL-only symbol 'rt_mutex_destroy' make[2]: *** [scripts/Makefile.modpost:91: __modpost] Error 1 looks like this might fix it (not tested it though it):

Petro commented on 2016-10-26 21:48 (UTC)

@dvzrv Thanks, still learning my way around.

dvzrv commented on 2016-10-26 20:02 (UTC)

@Petro: Wherever you're compiling is running out of space. If you're compiling in tmpfs you might want to switch to some location on your harddrive, if your RAM is not big enough.

Petro commented on 2016-10-26 16:41 (UTC)

.tmp_kallsyms2.S:2:0: fatal error: when writing output to /tmp/cc3Gj1v7.s: No space left on device #if BITS_PER_LONG == 64 compilation terminated. make: *** [Makefile:949: vmlinux] Error 1 Any help?

jhernberg commented on 2016-10-22 19:05 (UTC)

Was going to wait for 4.8.3-rt, but I've updated and added a fix for CVE-2016-5195. Haven't tested this build much, but have run 4.8-rt on and off for a few weeks without any apparent problems, so I think this is good to go. Enjoy! ;)

Det commented on 2016-10-22 11:10 (UTC)


jhernberg commented on 2016-09-03 14:25 (UTC) (edited on 2016-09-03 14:26 (UTC) by jhernberg)

4.6.7_rt11-1 contained a performance regression in dcache. Highly recommended to upgrade to 4.6.7_rt11-2, which if it doesn't entirely fix it, at least comes close.

cyberwoodman commented on 2016-08-30 09:08 (UTC)

Here is workaround: echo keyserver hkp:// >>~/.gnupg/gpg.conf Then manually import those keys: gpg --recv-keys 79BE3E4300411886 gpg --recv-keys 38DBBDC86092693E gpg --recv-keys 7B96E8162A8CF5D1

cyberwoodman commented on 2016-08-30 08:39 (UTC)

==> Verifying source file signatures with gpg... linux-4.6.tar ... FAILED (unknown public key 79BE3E4300411886) patch-4.6.7 ... FAILED (unknown public key 38DBBDC86092693E) patch-4.6.7-rt11.patch ... FAILED (unknown public key 7B96E8162A8CF5D1) ==> ERROR: One or more PGP signatures could not be verified! ==> ERROR: Makepkg was unable to build linux-rt.

jhernberg commented on 2016-08-24 11:34 (UTC)

@oberon: I'll build myself a NO_HZ_FULL kernel and test some. Regarding vbox modules, I'll let that sleep as I don't maintain any vbox packages, and no one has complained so far. Personally I prefer using qemu, though I use it very sparingly.

oberon2007 commented on 2016-08-23 23:36 (UTC)

The NO_HZ_FULL seems to do what it should and no complaints sofar ;) Here's our config: For the vbox-modules it should be enough to locally edit your /usr/src/vboxhost-5.1.4_OSE/vboxdrv/r0drv/linux/timer-r0drv-linux.c like in this patch just with (4, 6, 0) instead of (4, 8, 0). Like that you should be able to build the modules for 46-rt. It will just fail for regular linux46 and 47 then ;)

jhernberg commented on 2016-08-23 17:19 (UTC)

@oberon: Thanks for the nvidia hint, next week I'm on vacation, so I hope to find some time to mess around with nvidia-dkms. We've had copyright problems before, so I'll see what I can come up with, though I'm suprised that this is the reason this time. Regarding vbox modules, as no one has complained yet, and I have no way personally to change the vbox modules package I've ignored the entire thing ;) Googling the nvidia problems I came across some manjaro linux-rt discussion. How is CONFIG_NO_HZ_FULL turning out for you? Iirc I had it on for a short while, but removed it as it didn't seem to help anything, and iirc it was printing the occasional warnings in the kernel msg buffer.

oberon2007 commented on 2016-08-23 16:27 (UTC) (edited on 2016-08-23 16:32 (UTC) by oberon2007)

To fix the vbox-modules not building is a little harder. I have patched the vbox-dkms-modules and built in an extra kernel define in the 46-rt kernel: With these dkm-modules you can then also build the linux-rt-virtualbox extramodules... :P If you don't need to compile any vbox-modules against other kernels, patching vbox with just >= KERNEL_VERSION(4, 6, 0) instead of (4, 8, 0) will be fine without changing anything in the kernel. But you still have to compile your patched vbox-dkms first...

oberon2007 commented on 2016-08-23 16:20 (UTC)

The unofficial dirty hack looks like this:

oberon2007 commented on 2016-08-23 16:17 (UTC)

nvidia's MIT license forbids the use of rt_mutex_destroy, therefor: FATAL: modpost: GPL-incompatible module nvidia-drm.ko uses GPL-only symbol There is no "officially clean" fix for this ;)

jhernberg commented on 2016-08-23 14:09 (UTC)

This solves CVE-2016-5696. Unfortunately the latest nvidia-dkms doesn't seem to work, but I downgraded nvidia-dkms to 367.35 which appears to work.

jhernberg commented on 2016-08-10 13:53 (UTC)

@habys: Look at this: ttps:// Do something like $ "gpg --recv-keys 79BE3E4300411886", etc.

habys commented on 2016-08-10 01:23 (UTC)

I see a signing error ==> Validating source files with sha256sums... linux-4.6.tar.xz ... Passed linux-4.6.tar.sign ... Skipped patch-4.6.5.xz ... Passed patch-4.6.5.sign ... Skipped patch-4.6.5-rt10.patch.xz ... Passed patch-4.6.5-rt10.patch.sign ... Skipped config ... Passed config.x86_64 ... Passed linux-rt.preset ... Passed change-default-console-loglevel.patch ... Passed fix-race-in-PRT-wait-for-completion-simple-wait-code_Nvidia-RT-160319.patch ... Passed ==> Verifying source file signatures with gpg... linux-4.6.tar ... FAILED (unknown public key 79BE3E4300411886) patch-4.6.5 ... FAILED (unknown public key 38DBBDC86092693E) patch-4.6.5-rt10.patch ... FAILED (unknown public key 7B96E8162A8CF5D1) ==> ERROR: One or more PGP signatures could not be verified! ==> ERROR: Makepkg was unable to build linux-rt.

abique commented on 2016-08-08 14:22 (UTC)

This thing should go into [core] at some point...

oberon2007 commented on 2016-07-17 13:09 (UTC) (edited on 2016-07-23 07:25 (UTC) by oberon2007)

rt8-patch appears to not be working with virtualbox-dkms modules. See:

jhernberg commented on 2016-07-17 12:07 (UTC)

@budimanjojo: It used to be like that for 4.4-rt, but IIRC I had to remove it for 4.6.2-rt5 as there was no patch in the older subdir. I have changed it back in 4.6.4_rt8-2 as it seems to work again. On the other hand I had to remove it from linux-rt-lts, as the 4.4.15-rt23 patch seems to be missing from the older subdir now :S Even though I've raised the subject a few times with the -rt devs, it appears that they occasionally forget to put the new patch in the older subdir..

vashysk commented on 2016-07-17 04:17 (UTC)

@jhernberg I had a feeling it was, but I figured I would save other new arch users some time trying to figure it out. I 2nd @budimanjojo suggestion it would save you time replying to comments like when a new patch is released before you can update the PKGBUILD.

budimanjojo commented on 2016-07-16 19:09 (UTC) (edited on 2016-07-16 19:10 (UTC) by budimanjojo)

@jhernberg maybe you should change the source to the older folder like we did in our PKGBUILD: Because the newer patch will also get into that folder, not only older patches. :)

jhernberg commented on 2016-07-16 14:11 (UTC)

@vashysk: It's a recurring problem :S Each time a new patch comes out, the older patch gets moved to the "older" subdir, which breaks the build script.. Either change the path to point to the new location, or change _rtpatchver and run updpkgsums.

vashysk commented on 2016-07-16 06:43 (UTC) (edited on 2016-07-16 06:43 (UTC) by vashysk)

If new users like me are having trouble installing or upgrading linux-rt change lines 12 and 39 of the linux-rt PKGBUILD from: 12| _rtpatchver=rt6 30| 'e5789831210983feb5b7d7d6ce34b0d40f2da527f9b450835ebbd7b8155f64cf' To: 12| _rtpatchver=rt8 30| '663e11a98b4bde339223b58e4f1bf9b3c6cd8588aa63946a542a2c7385a54cd5'

SajeOne commented on 2016-07-16 03:04 (UTC) is returning 404. The link in the 4.6 directory seems to be:

Gimmeapill commented on 2016-06-14 21:07 (UTC)

Sir, it's a very good millesime. Much better than the 4.4 series.

jhernberg commented on 2016-06-13 18:47 (UTC)

@abique: Look at this: Do something like $ "gpg --recv-keys 79BE3E4300411886", etc.

abique commented on 2016-06-13 11:47 (UTC)

Getting this: ==> Verifying source file signatures with gpg... linux-4.6.tar ... FAILED (unknown public key 79BE3E4300411886) patch-4.6.2 ... FAILED (unknown public key 38DBBDC86092693E) patch-4.6.2-rt5.patch ... FAILED (unknown public key 7B96E8162A8CF5D1) ==> ERROR: One or more PGP signatures could not be verified!

jhernberg commented on 2016-06-12 14:24 (UTC)

Just bumped it to 4.6.2-rt5. Seems to work fine on my machines, must have made some mistake configuring when I tested 4.6.1-rt3

jhernberg commented on 2016-06-10 12:11 (UTC)

@blackhole: Yes I know. I have built it, but found that it worked really bad on my test machine... I haven't had time to dig into the reasons, but hope to find some, especially as I'd like to move linux-rt-lts to 4.4..

blackhole commented on 2016-06-10 07:05 (UTC)

Now 4.6.x is out

Gimmeapill commented on 2016-05-04 10:35 (UTC)

@jhernberg: this is really minor - just my laziness to edit the pkgbuild ;-) I could raise it upstream, but I don't think the official kernel maintainers want to encourage users to use the localmodconfig option. Otherwise they would probably have already enabled support for modprobedb:

jhernberg commented on 2016-05-04 10:21 (UTC)

@Gimmeapill: Is it really important? I like to track the main distro kernel buildscript as closely as possible. Could you maybe ask for it to be added to the -ARCH kernel, like that I'll add it here too. On the other hand it seems a small thing, so if you really really want it, I suppose I can add it..

Gimmeapill commented on 2016-05-03 16:55 (UTC)

Minor feature request: to add a commented out option line 115 for "make localmodconfig"

jhernberg commented on 2016-04-08 11:10 (UTC)

@ronjouch: Been looking at the kernel buildsystem, but I don't think that's the guilty party, maybe something goes wrong reading the load or so. Will drop this as I have many other things to do ;) If you want to I suggest you report the problem of building the kernel when using "-j -l6" to the kernel mailing list. Happy we found the problem though, now I'm just wondering what problem yagojrocket had.

ronjouch commented on 2016-04-07 22:15 (UTC)

@jhernberg alright. Didn't know chrt, trying it; thanks for the tip!

jhernberg commented on 2016-04-07 20:15 (UTC)

I'm not quite sure, but it fails on my machine too. I guess you might have found a bug...;) I find that the "-j -l6" is strange, it makes my system sluggish at times, and takes forever to build. I'd recommend using "chrt -i 0 makepkg" (or yaourt or whatever you use instead). Makes the whole build process run as idle priority, so runs nearly full throttle, except when you need the cpu for other stuff.

ronjouch commented on 2016-04-07 03:45 (UTC)

@jhernberg build succeeded with a default MAKEFLAGS :) . Thanks! I'm rather new to building C programs, can you help me understand what caused my "-j -l6" (I have eight cores) to fail?

jhernberg commented on 2016-04-06 12:15 (UTC)

@ronjouch: Can you install devtools, unpack the linux-rt source package somewhere and then run sudo extra-x86_64-build? This will create a chroot and install all needed packages into /var/lib/archbuild. Like that you are sure that everything needed to build is properly installed. If that works, you might have some problem with the openssl package on your system. Otherwise build with MAKEFLAGS="-j1" (/etc/makepkg.conf), I think the missing header file is generated earlier in the build process, and it's hard to tell what is going on with parallel build threads...

jhernberg commented on 2016-04-06 12:07 (UTC)

@Gimmeapill: Check out this paper:

ronjouch commented on 2016-04-06 03:30 (UTC)

@jhernberg hmmm no I think disk space is fine, it builds in /tmp which has 8GB left. Maybe will try without my AUR helper (yaourt).

Gimmeapill commented on 2016-04-05 20:12 (UTC)

@ronjouch & @yagojrocket: Builds fine here as well (no chroot)

yagojrocket commented on 2016-04-05 13:18 (UTC)

@jhernberg Nope, I had enough space on my system partition and I increased my /tmp partition size to 4Gb, at the very first time trying to install the rt kernel I really had a small /tmp partition and I ran out of diskspace, but it gave me another different error.

Gimmeapill commented on 2016-04-05 12:12 (UTC)

@jhernberg: thx for the hints! I already found my way with cyclictest and latencytop but didn't know about jack2 profiling, this looks extremely interesting.

jhernberg commented on 2016-04-05 11:27 (UTC)

@ronjouch & @yagojrocket: Is it possible that you guys run out of diskspace while building?

jhernberg commented on 2016-04-05 11:25 (UTC)

@Gimmeapill: I'd say that one definitely ought to have CONFIG_HIGH_RES_TIMERS=y. Yeah agreed about testing tools, there is however JACK2's profiling mode that can give a good insight into how often and well serviced the soundcard is, there is also cyclictest (in the rt-tests package) which can give an idea about how well kernel scheduling works. I'm not aware of any utility to test midi jitter...

jhernberg commented on 2016-04-05 11:15 (UTC)

@ronjouch & @yagojrocket: I've just built 4.4.6-rt13 with makepkg and in a chroot with devtools (extra-x86_64-build) without any problems..

Gimmeapill commented on 2016-04-05 10:29 (UTC)

@jhernberg: FYI, I reported it a while ago to the quickscan author (on the basis of the current linux-rt settings): For audio, I really couldn't find a difference with the 1000Hz tick activated. For midi, I suspect this is/was only valid for ALSA-MIDI and is not needed anymore with JACK-MIDI / a2jmidid (so highly configuration dependent). But the problem is I think the lack of easy to use measurement tools - both for audio and midi

jhernberg commented on 2016-04-05 10:07 (UTC)

@mitchk: It used to be a good idea to use the 1000Hz ticker many years ago, but it appears to me to no longer be needed. I changed this quite a long time ago, and no one so far has reported an issue. The only thing I'm not quite sure about, is that it has been claimed that 1000Hz was needed for tight midi timing, but so far I haven't found anyone that cares enough to test it for me, though I don't see how it could help.

yagojrocket commented on 2016-04-04 23:44 (UTC)

I got the same error on Arch, ronjouch. Tried 2 or 3 times, moved to a fresh install of Antergos, I tried again and got the same error, I gave up and I'm trying to install the rt-lts kernel, 4 hours and no problems until now, I have around 1Gb on my aur-linux-rt-lts folder at /tmp I don't know what's going on with linux-rt :/

ronjouch commented on 2016-04-02 18:34 (UTC)

Hi. Usually I have no build problem, but 4.4.6_rt13-1 fails to build, here's what I get: CC [M] drivers/crypto/ccp/ccp-platform.o drivers/crypto/qat/qat_common/qat_asym_algs.c:55:32: fatal error: qat_rsapubkey-asn1.h: No such file or directory compilation terminated. scripts/ recipe for target 'drivers/crypto/qat/qat_common/qat_asym_algs.o' failed make[4]: *** [drivers/crypto/qat/qat_common/qat_asym_algs.o] Error 1 scripts/ recipe for target 'drivers/crypto/qat/qat_common' failed make[3]: *** [drivers/crypto/qat/qat_common] Error 2 scripts/ recipe for target 'drivers/crypto/qat' failed make[2]: *** [drivers/crypto/qat] Error 2 make[2]: *** Waiting for unfinished jobs.... LD [M] drivers/crypto/ccp/ccp.o scripts/ recipe for target 'drivers/crypto' failed make[1]: *** [drivers/crypto] Error 2 make[1]: *** Waiting for unfinished jobs.... CC drivers/cpufreq/cpufreq_governor.o CC drivers/cpufreq/cpufreq_ondemand.o LD drivers/cpufreq/built-in.o Makefile:946: recipe for target 'drivers' failed make: *** [drivers] Error 2

mitchk commented on 2016-03-31 09:28 (UTC)

Please disregard my previous post. I looked at some older comments in regards to this issue. Mitch

mitchk commented on 2016-03-31 09:00 (UTC)

Hi, In checking the config.gz it looks like CONFIG_HZ is set to 300. Is this what is intended? When running realtimeconfigquickscan, it suggests a value of 1000. Is there a way I can modify this? Mitch

mitchk commented on 2016-03-31 00:53 (UTC)

Thanks very much.

Noroimusha commented on 2016-03-27 12:11 (UTC)

@mitchk: hi, you might find this Archwiki chapter interesting: .

mitchk commented on 2016-03-26 18:02 (UTC)

Hi, I tried building and received errors. Please see below: aura >>= AUR Packages: linux-rt aura >>= Continue? [Y/n] y aura >>= Building `linux-rt`... ==> Making package: linux-rt 4.4.4_rt11-1 (Sat Mar 26 13:57:29 EDT 2016) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Downloading linux-4.4.tar.xz... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 83.2M 100 83.2M 0 0 1802k 0 0:00:47 0:00:47 --:--:-- 1569k -> Downloading linux-4.4.tar.sign... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 473 100 473 0 0 564 0 --:--:-- --:--:-- --:--:-- 563 -> Downloading patch-4.4.4.xz... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 196k 100 196k 0 0 396k 0 --:--:-- --:--:-- --:--:-- 395k -> Downloading patch-4.4.4.sign... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 819 100 819 0 0 1519 0 --:--:-- --:--:-- --:--:-- 1522 -> Downloading patch-4.4.4-rt11.patch.xz... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 174k 100 174k 0 0 202k 0 --:--:-- --:--:-- --:--:-- 202k -> Downloading patch-4.4.4-rt11.patch.sign... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 543 100 543 0 0 1006 0 --:--:-- --:--:-- --:--:-- 1005 -> Found config -> Found config.x86_64 -> Found linux-rt.preset -> Found change-default-console-loglevel.patch -> Found 0001-sdhci-revert.patch -> Found fix-race-in-PRT-wait-for-completion-simple-wait-code_Nvidia-RT-160319.patch ==> Validating source files with sha256sums... linux-4.4.tar.xz ... Passed linux-4.4.tar.sign ... Skipped patch-4.4.4.xz ... Passed patch-4.4.4.sign ... Skipped patch-4.4.4-rt11.patch.xz ... Passed patch-4.4.4-rt11.patch.sign ... Skipped config ... Passed config.x86_64 ... Passed linux-rt.preset ... Passed change-default-console-loglevel.patch ... Passed 0001-sdhci-revert.patch ... Passed fix-race-in-PRT-wait-for-completion-simple-wait-code_Nvidia-RT-160319.patch ... Passed ==> Verifying source file signatures with gpg... linux-4.4.tar ... FAILED (unknown public key 79BE3E4300411886) patch-4.4.4 ... FAILED (unknown public key 38DBBDC86092693E) patch-4.4.4-rt11.patch ... FAILED (unknown public key 7B96E8162A8CF5D1) ==> ERROR: One or more PGP signatures could not be verified! aura >>= Well, building `linux-rt` failed. aura >>= Would you like to continue anyway? [Y/n]

jhernberg commented on 2016-03-20 15:02 (UTC)

4.4.4_rt11-1 released with a refactored nvidia fix. Seems to work fine on my test systems, but have only tested the nvidia module with bumblebee. Symptoms without this patch is that sooner or later the nvidia driver deadlocks and the screen freezes.

jhernberg commented on 2016-03-18 11:42 (UTC)

Am working on 4.4.4-rt11, but it breaks the nvidia patch that's been in use for a while. Seems like without the patch nvidia will still hang, so the patch has to be redone...

philm commented on 2016-03-15 18:19 (UTC)

The package is currently not working because there is already a new patch(rt11) out there and the old one is deleted or moved anywhere else.

Gimmeapill commented on 2016-03-07 20:26 (UTC)

Looks all good so far (Intel gpu - Ivy Bridge). Thanks for your efforts!

jhernberg commented on 2016-03-05 11:06 (UTC)

@dvzrv: Try this: I built it yesterday and it has been up and running on my main machine for over 16 hours. Seems like the problems have solved themselves as before it'd crash or hang in a matter of minutes. I'll deploy it on a few more systems today and if it remains stable I'll bump the linux-rt buildscript soon. Regarding patch-4.1.15-rt17.patch.xz I don't know what they did, but now has one timestamped 2:nd of March, so I guess it's ok/normal that the checksum fails.

dvzrv commented on 2016-03-04 14:29 (UTC)

@jhernberg: on the current build patch-4.1.15-rt17.patch.xz for some reason now has a changed checksum. Going to try 4.4.1-rt as soon as I find some time (hopefully soon!), as I also primarily use Intel GPU.

jhernberg commented on 2016-02-13 15:22 (UTC)

Here is a buildscript to a 4.4.1-rt kernel: Note that it creates a new package linux-rt-dev, so you might have to add it to your boot manager, and I haven't tested any external modules. Also note that it quickly locks my intel gpu system hard, and I haven't had the time needed to see if I can figure out what goes wrong.

jhernberg commented on 2016-01-28 15:25 (UTC)

Beh, scrap that. It did lock pretty hard, could still ping it, but local gui and even ssh login didn't work anymore... So try at your own risk ;)

jhernberg commented on 2016-01-28 13:11 (UTC)

If someone wants to test 4.4.-rt3 the source package is here: Seems to work fine so far (very limited testing).

jhernberg commented on 2016-01-24 11:57 (UTC)

For those wanting 4.4-rt, I'll build it and test it on my own system first, I might also wait a version or two before uploading it, as it normally has a few issues in the beginning.

jhernberg commented on 2016-01-22 20:38 (UTC)

@hdante: Look at this: Do something like $ "gpg --recv-keys 79BE3E4300411886", etc.

jhernberg commented on 2016-01-22 20:36 (UTC)

@Vi0L0: Yeah, you're absolutely right, done ;)

hdante commented on 2016-01-21 20:52 (UTC)

I'm getting "unknown public key" errors on this. Any ideas ? ==> Verificando assinatura de arquivo fonte com gpg... linux-4.1.tar ... FALHOU (chave pública desconhecida 79BE3E4300411886) patch-4.1.15 ... FALHOU (chave pública desconhecida 38DBBDC86092693E) patch-4.1.15-rt17.patch ... FALHOU (chave pública desconhecida 7B96E8162A8CF5D1) ==> ERRO: Uma ou mais assinaturas PGP não puderam ser verificadas!

Vi0L0 commented on 2016-01-21 11:57 (UTC)

it would be probably good to add this patch:

jankoppe commented on 2016-01-14 15:14 (UTC)

@jhernberg: did not see that. Sorry then!

jhernberg commented on 2016-01-12 10:14 (UTC)

@jankoppe: So far just a rebase to v4.4-rc6: see: I'm not going to rebase that onto the release kernel and package. We'll have to wait for the real patch!

jhernberg commented on 2015-12-30 10:00 (UTC)

@gjo: Thanks for letting us know. Am happy it's not the kernel config causing you problems!

gjo commented on 2015-12-21 22:29 (UTC)

@jhernberg: Sorry, you are right - my fault: I retried with 1000Hz and your default setting (m-audio delta 1010 pci, amd fx8xxx) rosegarden: no change - seems to be a loop bug in rosegarden muse2: everything is working fine - no timing issues (my fault, had problem with seq24 not muse2) So my midi-setup is working perfect with the default CONFIG_HZ setting/config. Sorry for my noise..

jhernberg commented on 2015-12-19 14:50 (UTC)

@gjo: Hi, I've been somewhat split over starting to use dyn ticks and reducing the ticker freq... Personally I only do audio work, and from all I can see, the kernel in it's present config works really well, both for audio but also for the rt-tests test suite. I know that the Internet lore says that you need 1000Hz for best midi timing, but haven't been able to find anyone that would test this for me. The config options that you might want to play with, would probably be dyntick (disable) and/or ticker freq. Also note that it might be hardware dependent, I only have Intel systems to test on. The midi hardware and/or usb could possibly also be an issue. Regarding hires timers they are enabled and ought to work well provided your hardware supports them. Would love to hear back from you if you find out something on this topic! I'd also love to get some easy test I can run to verify midi timing, as I don't want to configure a kernel in a way that causes problems for anyone...

gjo commented on 2015-12-18 23:53 (UTC)

@jhernberg: @erlhel: i do have timing issues: muse2 and rosegarden alerts something like: was unable to find high-resolution timing resource. seq24 has timing issues (midi sync) - i think CONFIG_HZ should be at least 500hz. i try to build and test one tomorrow

mdi commented on 2015-12-12 11:49 (UTC)

I'm getting the following error when trying to install the linux-rt-headers package: ==> Entering fakeroot environment... ==> Starting package_linux-rt-headers()... cp: cannot stat ‘arch//Makefile’: No such file or directory ==> ERROR: A failure occurred in package_linux-rt-headers(). Aborting... ==> ERROR: Makepkg was unable to build linux-rt.

jhernberg commented on 2015-10-11 16:28 (UTC)

@erlhel: Regarding the 1000Hz timer. I am relatively sure that it's no longer needed, and changed the timer to 300Hz a few releases back. So far no one has complained with scheduling problems, and I can't see any on my machine either. Regarding hwlatdetect, the program assumes that the driver is a kernel module and not built into the kernel. I messed up when I created the kernel config, have fixed it with the latest build script, and also sent a patch upstream to prevent it being built into the kernel, so hopefully I won't be able to mess it up in the future ;)

jhernberg commented on 2015-10-11 16:24 (UTC)

@Gimmeapill: Sorry that I didn't answer, been busy with other things and no time for archlinux :S Happy you found a solution though.

erlhel commented on 2015-10-05 16:52 (UTC)

I get this complaint from realtimeconfigquickscan: "Checking if kernel system timer is set to 1000 hz... not found - not good Try setting CONFIG_HZ to 1000" I get this problem when I run hwlatdetect: [root@antecekde ~]# hwlatdetect --duration=120 --threshold=15 Traceback (most recent call last): File "/usr/bin/hwlatdetect", line 465, in <module> detect = Detector() File "/usr/bin/hwlatdetect", line 158, in __init__ self.kmod = Kmod() File "/usr/bin/hwlatdetect", line 133, in __init__ self.modname = self.__find_modname() File "/usr/bin/hwlatdetect", line 119, in __find_modname raise RuntimeError("no detector module found!") RuntimeError: no detector module found! When I modprobe the modules I get this: [root@antecekde ~]# modprobe hwlat_detector [root@antecekde ~]# modprobe smi_detector modprobe: FATAL: Module smi_detector not found. [root@antecekde ~]# lsmod |grep hwlat [root@antecekde ~]# The code: class Kmod(object): ''' class to manage loading and unloading hwlat.ko''' names = ("hwlat_detector", "smi_detector") def __find_modname(self): debug("looking for modules") path = os.path.join("/lib/modules", os.uname()[2], "kernel/drivers/misc") debug("module path: %s" % path) for m in Kmod.names: mpath = os.path.join(path, m) + ".ko.gz" debug("checking %s" % mpath) if os.path.exists(mpath): return m raise RuntimeError("no detector module found!") hwlatdetect works nicely on the linux-rt-lts kernel, so maybe the cause is related to the kernel. As far as I understand the sound is good. No xruns when I did my first small test.

Gimmeapill commented on 2015-10-03 11:30 (UTC)

OK, that was the "-march=native" flag. For a reason beyond my understanding, on x86-64 with an Ivy Bridge cpu it doesn't improve performance at all. Getting back to stock arch build flags and everything is fine again.

Gimmeapill commented on 2015-10-01 11:09 (UTC)

@jhernberg: false alert. 4.1.5 (binary from archaudio) is performing fine with 300HZ and rebuilding 4.1.7 with 1000HZ doesn't change anything - I still get a few xruns. Well, there's still a perf degradation, but it probably has more to do with my build flags...

Gimmeapill commented on 2015-09-30 07:33 (UTC)

@jhernberg: I *think* there's a small perf degradation between the 4.1.5 binary in your repo and the current 4.1.7 that I tried to build (a few xruns instead of none on the same setup). I'll try to run a better A/B comparison by building again 4.1.7 with 1000HZ and let you know if it makes any difference...

jhernberg commented on 2015-08-11 12:23 (UTC)

I've bumped the kernel to 4.1-rt. One big change I've done is to use 300Hz instead of 1000Hz, so I'd be really interested if there are any noticeable downsides!

jhernberg commented on 2015-08-11 12:21 (UTC)

@funcmuscle I don't really think BFQ is all that relevant, but please let me know how it works out. I think what's important (for low latency audio) is that you keep the data on a dedicated drive. But am going to test a ssd in my laptop real soon now, and I might try bfq too.

funkmuscle commented on 2015-08-08 15:54 (UTC)

what about the BFQ RT kernel? gonna try it.. Been using the vanilla kernel and it's be wonderful with all my audio work. This kernel here for some reason will not start my USB wifi adapter.

jhernberg commented on 2015-08-05 15:56 (UTC)

@capoeira hold on to working kernel packages..! :)

capoeira commented on 2015-08-04 16:08 (UTC)

@jhernberg rt-lts still working fine for me. I have still not tested the latest 2 main kernels

jhernberg commented on 2015-07-29 10:15 (UTC)

@capoeira, sorry I forgot about you. I also am not quite sure anymore what to do about your problem, hopefully it goes away by itself :)

jhernberg commented on 2015-07-29 10:14 (UTC)

I just added a linux-rt-dev package, for those that want to be on the bleeding edge :)

capoeira commented on 2015-07-01 12:38 (UTC)

@jhernberg I have no clue how to aply the fix

jhernberg commented on 2015-07-01 10:31 (UTC)

@capoeira: have you tried the fix from the ubuntu bug thread?

capoeira commented on 2015-06-29 11:57 (UTC)

well, I seam to be the only one with Arch using HDMI with HDA Intel anyways: only found Ubunters with the same problem.

jhernberg commented on 2015-06-27 16:15 (UTC)

@copoeira: then i guess we have to wait for that to be fixed upstream, don't think I've seen any patches for it yet.

capoeira commented on 2015-06-26 23:40 (UTC)

happens in all Kernels @jhernberg......and only with my sandy bridge PC

jhernberg commented on 2015-06-26 19:17 (UTC)

@capoeira: is that specific to linux-rt, or does it break with vanilla too?

capoeira commented on 2015-06-25 21:01 (UTC)

lot's of problems with 4.x hum? my HDMI output is not working after 3.18, too

Gimmeapill commented on 2015-06-25 19:35 (UTC)

Continuing the discussion started there I'm back as well to 3.18 RT-LTS. No crash but better performance overall. So far I could not reach reall low latencies with the 4.x series. For reference, on 3.18-rt-lts, I can get jack to runs stable down to ~2ms @96khz (-r96000 -p64 -n3). BTW, please keep publishing binaries, they are very handy ;-)

Gimmeapill commented on 2015-06-07 15:45 (UTC)

@funkmuscle: as root just create a text file called something like "snd_seq_midi.conf", it should contain only the following line: snd_seq_midi save it under /etc/modules-load.d and you're done with bug

funkmuscle commented on 2015-06-07 12:09 (UTC)

vanilla-4.0.5-1 is out and still no midi.. Guess this will take some time. Sticking with the rt-3.18 for now..

capoeira commented on 2015-06-03 17:32 (UTC)


jhernberg commented on 2015-06-03 17:11 (UTC)

@vania: Look at this: Do something like $ "gpg --recv-keys 79BE3E4300411886", etc.

jhernberg commented on 2015-06-03 17:10 (UTC)

jhernberg commented on 2015-06-03 17:09 (UTC)

@capoeira: The repo unfortunately isn't signed, you need to do this: [archaudio-production] SigLevel = Never Server =$repo/$arch

vania commented on 2015-06-03 15:46 (UTC)

linux-4.0.tar ... NON RIUSCITO (chiave pubblica sconosciuta 79BE3E4300411886) patch-4.0.4 ... NON RIUSCITO (chiave pubblica sconosciuta 38DBBDC86092693E) patch-4.0.4-rt1.patch ... NON RIUSCITO (chiave pubblica sconosciuta 7B96E8162A8CF5D1) ==> ERRORE: Una o più firme PGP non possono essere verificate! ==> ERRORE: Makepkg non è riuscito a compilare linux-rt.

capoeira commented on 2015-06-03 12:53 (UTC)

@jhernberg I tried to install linux-rt-lts from audio-repro but it complains about missing key. problem is pacman doesn't show what key is missing

jhernberg commented on 2015-06-03 08:04 (UTC)

linux-rt-lts is now a 3.18-rt kernel, so ought to be a temporary workaround. Also seems more stable, have seen some strange things with linux-rt in the new 4.0.4-rt1 version.

jhernberg commented on 2015-06-03 08:02 (UTC)

I just looked through the config changes of the vanilla config (which this kernel is based on), and could find nothing that would prompt this, so I assume that it's really a vanilla kernel bug, and will at some point be fixed.

coderkun commented on 2015-05-31 20:40 (UTC)

@funkmuscle: Guess you are also affected by this bug: For me loading the module snd_seq_midi manually works as workaround (as suggested in the bug messages).

funkmuscle commented on 2015-05-31 20:35 (UTC)

problems with linux-4.0.4 rt and vanilla with the snd-ice-1712 module. I lost my midi in for my keyboard. Tried both kernels and no midi it. downgraded to 3.18 and it's back.

jhernberg commented on 2015-05-29 14:33 (UTC)

@blackhole: That really shouldn't happen, but supposedly it's not normally a problem. It happens when the kernel tries to go idle when there is a pending softirq. Would probably be worth to write a report to the linux-rt-users mailing list. If it bothers you, you can use the nohz=off kernel boot flag do disable dynticks.

blackhole commented on 2015-05-29 13:29 (UTC)

With kernel 4.0.4 I have this message at boot NOHZ: local_softirq_pending 40

jhernberg commented on 2015-05-29 08:39 (UTC)

To be honest I didn't know about these repos. We started archaudio a long time ago, but it seems like the packagers we have got tired and just put the packages on the aur, and people mostly use the aur. So archaudio is really underused...:( I started uploading binaries a few years ago, as I thought many people would probably like to download a binary instead of building a kernel or wine. Have no idea how many downloads it sees though, maybe I'm doing it for no one :) Personally I'd be really happy if we could get enough packagers together to host most (all) audio packages on archaudio (or the coderkun repos), but I don't think this will happen. After all with the aur we have a different situation to most other distros... One think which is bad is that we don't sign the packages... Btw coderkun, there is really no need to build the kernel with the performance governor anymore, as it works to change it at runtime nowdays. Used to broken for a long time though.

coderkun commented on 2015-05-28 19:02 (UTC)

@capoeira: I regularly build the -rt kernel myself with default CPU governor set to performance and a few other audio applications I use but it would be good to share work instead of doing everything twice.

capoeira commented on 2015-05-28 17:45 (UTC)

nice, I also found this repro: why don't you work together?

jhernberg commented on 2015-05-28 16:06 (UTC)

FWIW, I've updated the archaudio-production repo, and added nvidia-rt too.

funkmuscle commented on 2015-05-28 14:44 (UTC)

@blackhole: that worked.. thanx

blackhole commented on 2015-05-28 14:37 (UTC)

This was my method: 1) add keyserver hkp:// to /home/user/.gnupg/gpg.conf and AS USER gpg --recv-keys 79BE3E4300411886 gpg --recv-keys 38DBBDC86092693E gpg --recv-keys 7B96E8162A8CF5D1

funkmuscle commented on 2015-05-28 14:33 (UTC)

doing that guys but this is what happens: gpg: keyserver receive failed: No keyserver available

jhernberg commented on 2015-05-27 22:51 (UTC)

@funkmuscle: see:

capoeira commented on 2015-05-27 21:22 (UTC)

you get error for 3 keys, don't you? import them with: gpg --recv-keys "key1" gpg --recv-keys "key2" gpg --recv-keys "key3"

funkmuscle commented on 2015-05-27 20:50 (UTC)

@capoeira: explain to me how cap.. I want this don't right.

capoeira commented on 2015-05-27 20:47 (UTC)

@funkmuscle....never had this before, too....and always used this kernel. @Gimmeapill's solution worked for me. I imported the 3 keys my build complained at.

funkmuscle commented on 2015-05-27 20:41 (UTC)

@capoeira: I've used the kernel for a while now and this started recently for me. I tried to figure out what is said here: but it didn't work or I just can't figure it out so I use packer with this command: $: packer -S --skipinteg then after the packages are built, I got to the Tmp folder and run $: pacman -U that's the only way I can get it to upgrade. never had the key issues before with this rt kernel.

Gimmeapill commented on 2015-05-25 08:40 (UTC)

@capoeira: if you build this for the first time, you need to import a few keys with $ gpg --recv-keys 1234567890 (that should be Linus's, Greg Kroah-Hartman + another kernel dev whose name I forgot). Full explanation there:

capoeira commented on 2015-05-25 01:17 (UTC)

getting 3 unknown public key messages

jhernberg commented on 2015-05-23 08:40 (UTC)

@Gimmeapill: Great news, then we'll ignore the problem and hope that it just got fixed :)

Gimmeapill commented on 2015-05-23 07:00 (UTC)

@jhernberg: 3.18.13_rt10-1 is fine (binary from archaudio), I cannot reproduce anymore the issue.

Gimmeapill commented on 2015-05-15 18:11 (UTC)

OK, I didn't have time to do anything particularly useful, as I can hardly approach my computer those days, but I can at least confirm 3.18.9_rt5-2 is absolutely fine...

Gimmeapill commented on 2015-04-29 11:55 (UTC)

@jhernberg: Thanks, will give it a try and report back. I don't think as well that NOHZ is the culprit since disabling it had no particular effect. Right now I don't even have enough to open a bug report (no core dump or kernel panic message in the console) and I'm pretty worried by potential data corruption when the lock occurs (lost a couple inodes on my data filesystem already). If no luck I'll try to rebuild after enabling Kdump ( and get a proper crash dump, but I lacked time until now...

jhernberg commented on 2015-04-29 08:17 (UTC)

@Gimmeapill: You really get no indication at all on the screen what is happening? AFAIK, a blinking caps lock indicates a kernel panic. Don't think anyone else has reported anything similar, so would be really interesting to find out what has broken, but impossible for me to do as I don't see such a problem. The change to NOHZ happened in 3.18.9_rt5-2 so if that version works it's unlikely that this change is involved. I've uploaded the tarballs I built for 3.18.9_rt5-2 (x86_64) to dropbox, so you can grab them there: Please let me know if you find out something more, as it's unlikely to be fixed if no one else sees the bug... You might want to report it to the linux-rt-users mailinglist, or ask for help on the linux-rt channel on

Gimmeapill commented on 2015-04-23 21:04 (UTC)

RT LTS seems ok so far (Thanks for reminding me of its existence). As said, problems started with 3.18.11. The last known good version was 3.18.9_rt5-2. Nothing else system related was changed on that day (16/04). I wouldn't mind rolling back, but I didn't keep it as for once I cleared my pacman cache...

Gimmeapill commented on 2015-04-23 19:12 (UTC)

@jhernberg: sorry for the delayed answer, I hadn't enabled notifications. Yes, everything is absolutely fine otherwise, performance seems slightly better with the latest version. Only shutdown/reboot with sysctl or sysv compat. CPU is an i5 3317u in a toshiba u940 notebook with turbo boost disabled. Possibly something to do with my startup method (bare fluxbox xsession started automatically). It doesn't happen everytime but the hangs are pretty bad. I'll run more tests an report back.

jhernberg commented on 2015-04-22 07:26 (UTC)

@Gimmeapill: Does it cold boot ok, and just have problem with shutdown/reboot?

jhernberg commented on 2015-04-22 07:25 (UTC)

Can you try to downgrade to linux-rt-3.18.9_rt5-2, or possibly try linux-rt-lts to see if that changes anything? I run this kernel on a couple of i7 systems and have not seen any problems like this. The only problem I'm aware of is some AMD systems having had boot problems.

Gimmeapill commented on 2015-04-21 19:08 (UTC)

Nope - that didnt help. Getting back to stock kernel for the time being

Gimmeapill commented on 2015-04-21 07:54 (UTC)

report: I get frequent sytem locks on shutdown and reboot with the latest binary from archaudio (Intel notebook, no DE, just using systctl poweroff). No log or anything useful except a blinking caps lock key. It seems to happen more often after an audio session in performance mode ("cpupower frequency-set -g performance"). I'll try the nohz=off see if it improves anything.

jhernberg commented on 2015-04-18 19:44 (UTC)

@ilkytest: You have to either comment out the signature files from the source array, or add the pgpkeys listed in the PKGBUILD to you own key chain. See:

ilkyest commented on 2015-04-18 18:59 (UTC)

Error... unknown public keys linux-3.18.tar (79BE3E4300411886) patch-3.18.11 ( 38DBBDC86092693E) patch-3.18.11-rt7.patch (7B96E8162A8CF5D1)

jhernberg commented on 2015-03-31 11:08 (UTC)

I've just changed the configuration to "dynamic ticks" (CONFIG_NO_HZ_IDLE=y), please report if this causes any problems! Dynamic ticks can be disabled by booting with the kernel boot flag "nohz=off", which should restore the previous behavior of the periodic tick. For more details, see:

dvzrv commented on 2015-03-25 14:05 (UTC)

@jhernberg: In a way you're right. Arch Linux however (or pacman in particular) seems to still not offer a clean solution for its behavior ( But... to be honest, I haven't used it so far, as most modules were available for pre-made kernels I used (and that seemed to be the better solution).

jhernberg commented on 2015-03-25 09:05 (UTC)

@dvzrv: Thanks! Isn't dkms a good solution when one needs many modules added for several kernels? Can remember using that for nvidia rt support a couple of years ago (another distro).

dvzrv commented on 2015-03-24 15:59 (UTC)

And that's done, too:

dvzrv commented on 2015-03-24 15:15 (UTC)

@jhernberg: No need to. It's done: @UlrichH: Don't worry. Actually there was not much to be done, but to copy/paste/mod the original abs PKGBUILD :) I'm also thinking about doing vhba-module for -rt as you can't use cdemu-daemon on linux-rt otherwise. Then again, I rarely use it.

commented on 2015-03-24 14:43 (UTC)

Thank you guys, I'm sorry not to be better at this, I'm kinda stuck with this issue :/

jhernberg commented on 2015-03-24 11:27 (UTC)

@UlrichH: I think dvzrv is most likely right, you'd need a package built for the linux-rt kernel. Will see if I find some time tomorrow to make one. Have never used the package, but would interest me too.

dvzrv commented on 2015-03-23 15:37 (UTC)

@UlrichH: I think a separate package might be needed. bbswitch-rt. For linux-rt the bbswitch module is not placed in the correct directory. I was thinking about doing something like that but I haven't tested the bbswitch-hook stuff yet. Maybe later tonight. Will report back.

commented on 2015-03-23 12:26 (UTC)

Hi, I can't make bbswitch to load :/ Do you know this issue ? Should I add it to mkinitcpio.conf and rebuild ? Or use the bbswitch-hook ?

commented on 2015-03-23 12:25 (UTC)

Hi, I can't make bbswitch to load :/ Do you know this issue ? Should I add it to mkinitcpio.conf and rebuild ? Or use the bbswitch-hook ?

jhernberg commented on 2015-03-08 01:10 (UTC)

With working cpufreq ! :)

funkmuscle commented on 2015-03-01 15:47 (UTC)

@jhernberg, thanx.. by the way it happened with packer and aurget but I have it running now.

jhernberg commented on 2015-03-01 03:24 (UTC)

I don't use yaourt, so don't know the specifics, but hopefully this will help:

funkmuscle commented on 2015-03-01 02:51 (UTC)

@jhernberg, the same way I did the last one, yaourt -S

jhernberg commented on 2015-02-28 18:15 (UTC)

@funkmuscle: How did you try to upgrade? You need to add the keys to your system in order to be able to verify the signatures.

funkmuscle commented on 2015-02-28 17:32 (UTC)

when upgrading, I got this: Verifying source file signatures with gpg... linux-3.18.tar ... FAILED (unknown public key 79BE3E4300411886) patch-3.18.7 ... FAILED (unknown public key 38DBBDC86092693E) patch-3.18.7-rt2.patch ... FAILED (unknown public key 7B96E8162A8CF5D1)

blackhole commented on 2015-02-23 17:33 (UTC)

Yes! At least the first version of the patch is in kernel 3.18

jhernberg commented on 2015-02-23 17:25 (UTC)

@blackhole: Does 3.18-rt help you with DSD?

jhernberg commented on 2015-02-23 17:24 (UTC)

3.18-rt is here :) Think most things work, there were a lot of things fixed in -rt2. I have made the default governor powersave again, but there is a fix coming up for cpupower. Hopefully no showstoppers for anyone.

blackhole commented on 2015-02-04 09:21 (UTC)

Sorry for the delay, but I have contacted the author of the patches. The problem is that the new patches (, not the ones that are now part of kernel 3.18 that are missing the new format SNDRV_PCM_FMTBIT_DSD_U32_BE) are made for kernel 3.17 so I have some fuzz, offset and an error about quirks.c already patched. You can check easly in 5 minutes downloading the file with already modified PKGBUILD at I succeded in rt kernel compilation (with fuzz and offset) not applying one of the patches and the resulting kernel is working fine. For me it would be very good if linux-rt had these patches.

jhernberg commented on 2015-01-28 08:59 (UTC)

@blackhole: That's just the problem, I don't have all that much time at the moment. What exactly are the problems? I suppose I have nothing against including the patches if there are no showstoppers for anyone else.

blackhole commented on 2015-01-26 11:26 (UTC)

I ma trying to apply the DSD native patches to this kernel I am using these: (the official but not updated patches are here: I have made an archive with all the patches and already modified PKGBUILD If you have time...please take a look. There are some problems. Thank you.

blackhole commented on 2015-01-23 16:20 (UTC)

updated new up-to-date package for nvidia here:

jmx commented on 2015-01-20 11:07 (UTC)

Sorry, I meant 3.14.29-rt26 is out...

jmx commented on 2015-01-20 11:06 (UTC)

Since 3.14.28-rt26 is out, the URL to the RT patch in the current PKGBUILD is not valid anymore.

blackhole commented on 2015-01-17 13:25 (UTC)

Now 3.14.28-rt25 is out!

cptiglo commented on 2015-01-17 13:15 (UTC)

The http address for the realtime patch is no longer valid!

Gimmeapill commented on 2014-12-18 22:59 (UTC)

Impressive perf gain for audio: latency reduced from ~4msec to ~2msec without any dropouts with Focusrite 2i2 + ivy bridge nb (tested with guitarix + jack). Thx for the good work ;-)

mlerota commented on 2014-12-14 20:47 (UTC)

I have found the fix for intel cards :-). It doesn't have anything with Nvidia patch. It's just something in the kernel. To fix flickers and tear-downs in video, Create: /etc/X11/xorg.conf.d/20-intel.conf file and put this in: Section "Device" Identifier "Intel Graphics" Driver "intel" Option "TearFree" "true" EndSection This is from:

mlerota commented on 2014-12-14 12:40 (UTC)

Today I tried normal kernel and this doesn't happen. I will try without this nvidia patch but it could be something else. I will send you an email about older kernels. Tnx.

jhernberg commented on 2014-12-13 12:28 (UTC)

@mlerota: I don't think there is any functionality to recover older build scripts from the aur :S You could try using the linux-rt-lts package, or possibly comment out this line from the buildscript: patch -p1 -i "${srcdir}/fix-race-in-PRT-wait-for-completion-simple-wait-code_Nvidia-RT.patch" That said it might just be a bump in the road and have nothing to do with the nvidia patch. Does it happen on the normal kernel too? Otherwise let me know what kernel you need, and I'll upload the source package to dropbox.

mlerota commented on 2014-12-13 12:01 (UTC)

@jhernberg, where can I find old PKGBUILDs? I would like to use some older rt-kernels. This new config and rt-kernel may have fixed some Nvidia problems but created one little problem on Intel graphics. When you play 720p or 1080p content, video sometimes flicker. It's no so smooth like on older kernels.

djimenez commented on 2014-11-29 20:48 (UTC)

@jhernberg I updated my system a week ago and it works absolutely great (a pentium g3420 w/8gb ram using a nvidia gtx750 ti). I encountered a strange problem with circular dependencies when upgrading, which required uninstalling both linux-rt and nvidia-rt before the upgrade and then reinstalling after upgrading. I, for one, am very happy that the governor is changed to Performance by default as it can take a while to compile the kernel with the changed settings. For reference, with this setting, the cpu on my system idles at 30C. I'll still be using your package if you choose to change the governor and I have, but I'd much rather the other guys (those with stressed cpus that cant handle the performance setting for their audio work) where the ones taking the time and effort. Thanks for all the good work. Daniel

jhernberg commented on 2014-11-27 13:16 (UTC)

My conclusion is that setting the default governor to performance isn't a very good idea for most people, so unless someone screams very loudly I'll change it back soon. Anyone who needs to change governor can simply use linux-rt-lts instead which is a stable version of the patch and works fine. The only change I have to make to my system with it, is to add audit=0 to the kernel boot flags, so that user namespaces works.

jhernberg commented on 2014-11-16 16:25 (UTC)

There is no way of knowing what the next will be, upstream is now a hobby project.. We can always hope for a 3.18-rt.

blackhole commented on 2014-11-16 15:00 (UTC)

Yes, I think it is better to wait also because this will work only with the new version 1.029 of alsa. The next realtime kernel will be 3.18?

jhernberg commented on 2014-11-16 13:10 (UTC)

@FadeMind: Why do you flag the package out of date when it isn't?

jhernberg commented on 2014-11-16 13:07 (UTC)

@blackhole: Interesting, do you want me to add it to the kernel? I have no such devices and can't test if it works. Might be better to wait until the code moves into a kernel that is supported by the -rt patch and alsa gets updated?

blackhole commented on 2014-11-14 12:24 (UTC)

I would like to let you know that I have sucessfully applied the kernel patches at to linux-rt kernel for linux DSD native playback (for making it work it is necessary to compile also alsa-git)

jhernberg commented on 2014-11-14 12:16 (UTC)

@capoeira: Does it work? AFAIK cpupower is broken for everyone using recent -rt kernels, what hardware if I may ask?

capoeira commented on 2014-11-14 10:12 (UTC)

I guess almost everybody here uses qjackctl under "execute script after startup" I have: sudo cpupower frequency-set -g performance under "execute script after shutdown" I have: sudo cpupower frequency-set -g ondemand

jhernberg commented on 2014-11-12 12:35 (UTC)

@sm4tik: yeah, i guess that's why. I am really considering changing the default back to ondemand, but let's wait a while and see if there are any other comments. I guess the few people that need performance could change the config and build the kernel themselves?

sm4tik commented on 2014-11-11 23:02 (UTC)

I'm having my vcore at max the whole time with the latest. Would it be because of the governor change? The freq does get lowered, but the voltage stays up. Downgraded to the earlier version and the voltages are ramping up/down normally. If this is the expected and wanted behavior, I'll just rebuild it myself with on-demand, no problem.

jrdnjhntn commented on 2014-11-01 23:05 (UTC)

@jhernberg - ah, no need to thank me really, it was the boys at national instruments that wrote that patch - I just made sure to pick it up - even if the RT devs chose not to, or maybe overlooked it ;)

jhernberg commented on 2014-11-01 16:50 (UTC)

I forgot, thanks @Ninez for finding the patch to fix NVIDIA hangs.

jhernberg commented on 2014-11-01 16:49 (UTC)

A few changes to the package as of 3.14.23-rt20-1: Updated the buildscript to more closely resemble core/linux. Added support for early microcode. Added a patch that stops NVIDIA from hanging on some cards. Changed the default governor to performance (since it's impossible to change governor on linux-rt due to a bug). If this impacts you negatively, please report it and I'll consider to change the default back to powersave.

jhernberg commented on 2014-11-01 16:35 (UTC)

@hyshka: Never tried, is it broken?

hyshka commented on 2014-10-25 18:31 (UTC)

Has anyone gotten linux-rt running with BTRFS?

jhernberg commented on 2014-10-22 09:23 (UTC)

@blackhole: btw, thanks for the information about oscilloscope. I already had it on my system (through tuna), but back when I read about oscilloscope, i never could find it. Didn't realize that it had been installed through tuna :)

jhernberg commented on 2014-10-22 09:20 (UTC)

@blackhole: Yeah, the /sys/devices/system/cpu/intel_pstate interface for manipulating P states is cpu specific. The /dev/cpu_dma_latency interface for manipulating C states ought to be available on most systems though.

blackhole commented on 2014-10-21 13:54 (UTC)

Unfortunately on my intel i5 M560 I don't have "sys/devices/system/cpu/intel_pstate/min_perf_pct" only acpi_cpufreq is loaded. Reading this I have found a solution (see my post before)

jhernberg commented on 2014-10-20 20:22 (UTC)

On the intel pstate driver (sb+ I think) I do "echo 100 > /sys/devices/system/cpu/intel_pstate/min_perf_pct" which makes the cpu run at max multiplier without any noticeably higher temps. I use the following script to limit how deep into C states the processor can go: #!/usr/bin/env python2 import os import sys import os.path import signal import struct if not os.path.exists('/dev/cpu_dma_latency'): print "no PM QOS interface on this system!" sys.exit(1) if len(sys.argv) == 1: qos_target = 0 elif len(sys.argv) == 2: qos_target=int(sys.argv[1]) else: print "Syntax is: pm_qos [maximum latency in usecs] (default is 0)" sys.exit(1) try: fd ='/dev/cpu_dma_latency', os.O_WRONLY) os.write(fd, struct.pack("i",qos_target)) print "Writing", qos_target, "to /dev/cpu_dma_latency" print "Press ^C to close /dev/cpu_dma_latency and exit" signal.pause() except KeyboardInterrupt: print "closing /dev/cpu_dma_latency" os.close(fd) sys.exit(0) # pm_qos 0 makes the cpu stay in C0 # pm_qos 1 allows it to go into C1 too. # pm_qos 80 allows it to go into C3 too, etc. You can get the target values from doing: # find /sys/devices/system/cpu/cpu0/cpuidle -name latency -o -name name | xargs cat

blackhole commented on 2014-10-16 22:50 (UTC)

At last I have solved the problem: 1) I have compiled the kernel with performance as default governor 2) I have added "“intel_idle.max_cstate=0" to linux-rt kernel line. Now in rt-test with oscilloscope I have a very low average latency of 3us and max also very low (in various tests I arrived to 18us max!) Maybe it not very safe for the processor in some cases, but for my i5 M560 temperature is 10° degrees higher (around 55° when idle)

coderkun commented on 2014-10-16 16:04 (UTC)

@blackhole: I compile the kernel with “performance” as default governor by setting the kernel config parameter CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y. (But the intel_pstate driver is buggy, I think)

blackhole commented on 2014-10-16 10:27 (UTC)

How do you set governor to performance? In standard arch kernel echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor >/dev/null or frequency-set -g performance is working but both are not working in linux-rt (same computer)

coderkun commented on 2014-10-15 18:23 (UTC)

@jhernberg: I always change the default governor to “performance” anyway, so please do so. Unfortunately the intel_pstate driver does not set the governor/frequency properly. But this is no news.

blackhole commented on 2014-10-15 15:33 (UTC)

I agree with performance governor.

jhernberg commented on 2014-10-15 13:10 (UTC)

Would anyone mind if I build the next kernel with the performance governor as default (for the people being inconvenienced by only having powersave available)?

blackhole commented on 2014-10-13 20:52 (UTC)

oscilloscope is part of the tuna application just released on AUR! Old but interesting:

jhernberg commented on 2014-10-13 18:51 (UTC)

@blackhole: The lower scheduling latency while running hackbench is most likely due to the CPU not going into powersaving anymore. That said it seems unlikely that 40usecs (?) latency would lead to audio dropouts. Did earlier kernels work better? BTW, where did you get the oscilloscope program, been wondering about that for a while.

blackhole commented on 2014-10-13 17:20 (UTC)

I have always problems with the last kernel: 1) If I start "cyclictest -t1 -n -p99 -i100 -o10 -v | oscilloscope -s1000 >/dev/null" I have a latency Average of 30 (very variable) or more and max of 40 or more 2) If I start "cyclictest -t1 -n -p99 -i100 -o10 -v | oscilloscope -s1000 >/dev/null" AND "hackbench -l 10000" I have the average around 6 and a max of 10 See also the image I have published at The everyday performance also is worse. Using HQplayer for upsampling in realtime from PCM 44.1 to DSD128 bitstreaming I have a lot of dropouts.

mlerota commented on 2014-10-07 10:14 (UTC)

@Nognir: The problem is in BTRFS. I could not run any rt kernel with BTRFS.

jhernberg commented on 2014-09-29 15:14 (UTC)

@Nognir: Sorry about the late answer! I am not quite sure what your problem is, but I know that some AMD cpus have had problems booting -rt kernels for several major versions now, though I did get one report about such a system finally booting with 3.14.rt9. Seems likely that this would be your issue. You could try and see if that kernel works, I know that the packager of that kernel had some experience with the AMD problem, and maybe knows more or has a workaround. @Ninez: Any news on the AMD issue?

Nognir commented on 2014-09-24 12:43 (UTC)

I attempted to install this kernel in order to set up my laptop as a portable DAW - but there was a freeze at loading the ramdisk at boot. The filesystem is BTRFS and my CPU is AMD M320. Is there any workaround or should I wait for a release based on a newer kernel? The vanilla, lts, and -ck kernels worked fine though

jhernberg commented on 2014-08-17 18:20 (UTC)

@Ninez: Yeah, nothing beats real life empirical tests. But on a theoretical level SMT simply isn't appropriate for deterministic realtime. First of all my contention is that intel prosumer cpus have a deficient cpu cache and could be suspectable to cache depletion. If your audio thread has to wait for the cpu cache to be loaded from memory again, then you are out of luck as that can take quite some time. The second point is that the scheduler might run SCHED_NORMAL threads on the sibling CPU stealing cpu power from your realtime threads, so that would break the entire concept of deterministic realtime. Not sure that is worth a ~30% increase in cpu. But hey, if it works then all is good, and theory be damned :) P.S. why don't you install an irc client and come visit #archaudio, #opensourcemusicians, or #lad on freenode. Would be a lot quicker to discuss things there instead here on the aur. Would also litter the comments less, but maybe it's good these discussions are saved for posterity as it might help some of our users. In any case best of luck with your experiments, and thanks for packaging tuna, looks like a nice shiny toy to have around :)

jrdnjhntn commented on 2014-08-17 17:37 (UTC)

@jhernberg - I initially thought that what i was observing was possibly due to SMT [even likely], but I now have been kind of wondering if it wasn't possibly related to Intel my GMA4600/ipgu, X and/or compiz. I say this because my observation was that it tended to be tied to X/compiz/igpu somehow. [that's also why i want to run non-X, non-accel'd X [possibly diff intel accel methods], X + no compiz tests]. I should clarify - the odd xrun at that extreme load, doesn't just "happen", but IIRC i could trigger the odd one, when doing certain types of operations with compiz/X; expo or maybe viewport switcher (that's about it) [and it didn't happen all of the time, just the 1/80 maybe even 1/100+ times.]. ~ none of this happened even at 99.x DSP load in jackd or less {with all 8 cores max'ed out} let alone any real-world use - where it doesn't happen at all, thus far. [and it's had ample opportunity to do so!]. But I also have changed some settings around on my box [a few processes are pinned, they weren't before + IIRC, there was more of the system making use of hyper-threading. but now, it's very limited], since that last run through those tests. (I'm gonna have a go, today, at it/testing more). It's possible, even probable -that this isn't happening anymore. [and like i said - not the easiest to trigger even under very very extreme conditions, anyway]... Yesterday, I had a mountain of NI/vst plugins going, sequences/midi/program changes, looping, routing, etc - the box just purrs like a kitten, no xruns ;) *I can easily be doing anything/everything else -> ie: compiling linux, wine, firefox/streaming HD vids, etc >> all, at the same time, if i like. Nothing seems to bother jackd/pulseaudio/snd-usb-audio/1818VSL or my highest rtprio apps/threads. It just hums along, (even) with SMT enabled. that's been my experience so far, with this particular box. :) ...

jhernberg commented on 2014-08-17 14:35 (UTC)

Yeah, that would be an indication that there might be some SMT problems. IME it will also happen at lower dsp load. Not often but every once in a while. Personally I prefer to test it at the limit, like that I am certain that it will work fine at lower cpu loads too. But like I said, it's possibly just a theoretical problem as it's highly unlikely that a system would have a 200+ load avg while it's used for recording :) But all in all, I don't mind losing the ~30% cpu that SMT might give me, as the cpus I use are fast enough to cope with anything I can throw at them audio wise. :) I get the impression that linux audio is just getting better and better. With a -rt kernel even USB and FW audio seems capable of very low latency. All in all very nice for us :)

jrdnjhntn commented on 2014-08-17 13:40 (UTC)

@jhernberg - I've done tests like that already. I have a script that launches 5 instances of NI Guitar Rig 5 - each instance loads a nasty/heavy preset [the kind that use abnormally high CPU] and I serialize the connections. After Jack is sitting around 99.x% to 100% DSP load, i then will get hackbench, or other scripts that can induce 100%+ CPU load / trouble ;) The result is that jackd will start to get the odd xrun. [but much less than i would've expected]. Without creating/simulating 100% cpu load, I don't have to worry about xruns until jackd is at around > 99% DSP Load. [it pretty much needs to be sustained over 100%, ie: 97% = still no xruns ... I would have expected xruns to creep in around the > 80% [possibly even 50-60%] DSP load, depending. But that doesn't seem to be the case. DSP load needs to be obscenely high, before it's a potential problem. [I haven't gotten around to it yet - but i want to do these tests without X running too]. I was actually a little shocked that the Presonus 1818VSL usb[2] audio device works this well. [and yeah, I give it very high rtprio]. I do unbind the wifi device [which uses internal usb3], but it's on another bus anyway. I've never had much faith in USB audio - but I seem to be 'gladly mistaken'. On lts - thanks that is helpful. I'll have a look.

jhernberg commented on 2014-08-17 08:38 (UTC)

@Ninez: IIRC he has tried all builds when they came out, but it was linux-rt-lts 3.10.47_rt50-1 that started working for him. I have a Hasswell laptop too, but I'm not sure whether I tested it or not. Well as long as you don't get xruns, it's all academical right :) Maybe try to run a full audio setup processing audio and then run hackbench and some other "torture" programs at the same time to see if xruns or not.

jrdnjhntn commented on 2014-08-16 17:50 (UTC)

@jhernberg - yup. that is the issue - even with finding the patch that broke things on some AMD - i still have no idea why...lolz - that being said - i will take your lts for a spin - do you happen to know _when_ your amd user reported success? [like linux's minor number maybe? - if so, i could take a look through the commits, as well - see if anything jumps out]. On SMT - Yeah, i believe Intel has fixed the issue on Haswell/gen4 i7. [yours is gen2 right?]. Anyway, leaving SMT on, seems to be okay [I tested both on/off and i really didn't see much benefit to disabling it on my box... you might squeeze slightly more deterministic behavior, but I like to strike a balance between high-performance/throughput and determinism. Also, I do a bit of cpu/process accounting, and only certain processes even run on my hyper-threads anyway. On SSD - yeah, a good SSD is one thing, but I've always been fascinated by the PCIe SSDs ~ and obviously since M.2 ports are "Next generation form factor" and use nvme like the pcie SSDs [unlike normal SSDs], they should smoke normal SSDs - my manual says the spec can support upto 16gb/s, which is crazy [and none on the market come close to that yet!]. Regardless, I am buying a 256gb M.2 drive, this coming week :) - I just hope NVMe [M.2 native mode] works well with RT.

jhernberg commented on 2014-08-16 13:31 (UTC)

@Ninez: If there is a fix for the AMD problem, I most certainly hope it will be in 3.16-rt, but I suppose there is no way of knowing without testing or actually knowing what the real problem is. Regarding SMT, I guess it's mostly an artificial problem as I have to go out of my way to provoke it. One can certainly hope that intel fixes the problem in hardware as afaik it really is a hardware problem. I think I have to buy a good SSD someday, but so far I really haven't needed it as rust seems to be fast enough for my track counts, and the laptop I just suspend to ram. But even when booting it, it's really quick. But definitely on my list of things to buy someday :)

jrdnjhntn commented on 2014-08-16 12:05 (UTC)

@jhernberg - the amd/linux-rt-lts turn of events is interesting - when i get some time i will build -lts on my AMD box to test. Then see if i can see what commit fixed things. [mind you if 3.16-rt gets release, i would think that it contains the commit, no?]. Regarding cooking cpu - yeah, it takes a fairly artificial circumstance for that to happen. [cooling is fine on this box, as well]. I haven't found a real-world work load that can actually spike temps like that [yet]. Also, yes, I am aware of min_perf_pct - as it is set in my profile. on SMT - I don't think it is an issue on this gen4 i7. I've had uptime from a few days to a week - ZERO xruns. [and that's with USB audio; with somewhat hifi/low latency settings]. Maybe some of the new cpu features are making the difference, like lock elision or Intel may have addressed that problem in another way, i don't know. [btw, I now have this machine rocking the 'mid-teens' in cyclictest :)] btw, I am picking up an M.2 form factor SSD. [and will likely be re-installing the system]. It should be interesting to see how NVMe benefits my systems. my current SATA6 SSD is fast, but these new SSDs/M.2 look amazing [my mobo has a port for one on the back / no pcie adaptor needed].

jhernberg commented on 2014-08-16 11:23 (UTC)

@Ninez: Thanks for the new packages, and congrats on the new hardware! Will take a look at the packages when I get back home from vacation. Regarding "cooking" your cpu, if so you most certainly need to fix the CPU cooling problem as (imo) this shouldn't happen on a decently assembled system. Hopefully your kernel is also well configured and would throttle the cpu long before that becomes a problem. Having insufficient cooling would be a danger in most any circumstance for instance compiling software etc. When using cyclictest you can use the --latency parameter set the value written to /dev/dma_cpu_latency. On i7 hardware I'd urge you to investigate /sys/devices/system/cpu/intel_pstate/min_perf_pct, writing 100 to it, will cause the pstate driver to ramp up the cpu freq to max very quickly while still using some C states. Seems like a good compromise as it appears to work well on -rt when the computer is busy, and still leave the cpu nice and cool when the system is idling. Setting /sys/devices/system/cpu/intel_pstate/max_perf_pct to a value under 100, would also be a good way to stop your cpu from being able to overheat as it would reduce the max turbo multiplier allowed. Regarding SMT causing cache depletion, it's unlikely that you would see that just running jack and cyclic test, but might be a potential problem and a source for xruns in real life. I'll keep disabling hyperthreading on my own i7 systems as I'm convinced that it occasionally can cause problems. Did you ever find the commit breaking AMD cpus? I've gotten one report that an AMD system that was borked before can boot with the latest linux-rt-lts, but it's apparently still borked with linux-rt. Hopefully this fix will percolate to the next linux-rt all by itself, but I thought I'd ask as you were one of the people in a position to find the problem. It looks like the next linux-rt release may be a 3.16-rt kernel and if so I will update linux-rt-lts to 3.14-rt as archlinux has bumped -rt-lts to 3.14 and I personally have problems with -rt-lts on my intel gpus. Still I don't want to break these kernels for anyone, but without the hardware to track down the bug, there is really precious little that I can do about the situation :(

jrdnjhntn commented on 2014-08-12 16:51 (UTC)

@jhernberg - So i have a new box up and running; Intel Core i7 4790 [Haswell] 16gb of DDR3 ram 250 SSD sata 6g ASUS Z97i-plus [mini-itx] Presonus 181VSL [usb2 class compliant audio interface] No shared irqs, excellent MOBO layout. Even with hyper-threading enabled; no > MAX: 20 in cyclictest [in fact, it mostly stays around MAX: 15 :)!! ]. Anyway, since i have a new machine with more power, I decided to package up some tools that i use for managing my systems ~ in case you are interested; i've packaged some system tuning tools from RHEL/MRG into AUR. - Tuna: Thread and IRQ affinity setting GUI and cmd line tool: ... this tool can handle cpu/irq affinity, cpu isolation, tuning a number of procfs interfaces [and it's extendable] and does so dynamically [meaning you isolate a core and it will update other processes/affinity accordingly] + you can also create/save/use your own profiles. Tuna is used in Enterprise linux for this type of sysadmin'ing and is better than any other tool I am aware of, for this purpose. [it can replace rtriq and similar tools, user scripts, etc]. [I've also included the RHEL pdf in this package]. - Tuned: A dynamic adaptive system tuning daemon [power management]: ... This tool allows the user to do things like control PM profiles. ie: [assuming tuned.service is running] $ tuned-adm profile latency-performance [this profile sets /dev/dma_cpu_latency to 0 ... which is probably better than using a kernel module to statically set it, or running cyclictest to do so. [as you were discussing recently]. After all, pmqos accepts 0-200 value, divided based on # of available states ~ meaning in some situations you may want to limit pmqos/states - but not totally ditch it [ie: setting to zero, then having extended cpuload - in theory, could cook your cpu. * It's not theory actually, i have tested it; the end result being my cpu [if i allowed it to continue] would have cooked itself / almost hit 'critical' levels [like another five mintues and the cpu would have been boiled/dead, probably] - re-enabling even the most modest/conservative settings, made the cpu barely hit it's "high" threshold, even under hours of 100& load/8 cores && 100% dsp load in jackd.]. anyway, I just thought i would point out these tools to you / anyone else interested. cheerz

jhernberg commented on 2014-07-16 17:42 (UTC)

@djimenez: rt-tests is here on aur, and also in the archaudio-production repo. I tried again to run -rt on my q6600 with nvidia gtx-650ti, and it hangs the screen output the moment I try to watch a video or something like that..:( Maybe it's just my card, but it does work flawlessly both for video watching and game playing in the vanilla kernel :(

sekret commented on 2014-07-16 10:45 (UTC)

_releasever=12 _rtpatchver=rt9 md5sums=('b621207b3f6ecbb67db18b13258f8ea8' '89a5af1f3609d0c27e63fea298dd80ed' '2aa3614e488efa939007a1c428406c30' '0c27345e34e944d4bc1c512f14742209' 'a8126ad28c0a902a575397cacd099db2' '843119a441c942efc5ec4b73c3c6ced5' 'eb14dcfd80c00852ef81ded6e826826a' '98beb36f9b8cf16e58de2483ea9985e3' '6839ddec74a5300beff1709a81b0e4f3' '706549e8a05f33f7fc697f28c0ca71d2' 'd23fc66be93ebce698bd7da844789de1' '16a161979f846b049e90daea907c35dd')

djimenez commented on 2014-07-10 00:54 (UTC)

That's correct, I had done nothing special upon installation of nvidia-rt. The pentium i have is just like an i3, but with HT turned off in hardware, so I kind of skipped that bug I guess. The reason why I didn't go with the "echo 100 > /sys/...' method is that there was no ../intel_pstate/ folder in my system at that address, so I decided against that as a temporary measure, then forgot about it. Should I make the file specifically? (I'd try it, but there was something odd about /sys and making folders there, right?) I'm not really sure that using the -rt kernel that i've installed offers great improvements in audio performance or latency, but I haven't done any real tests to try and prove it. It works great for the moment and that's ok. Additionally, I couldn't find the rt-tests package that you'd mention. Daniel

jhernberg commented on 2014-07-09 08:30 (UTC)

@djimenez: I'd still urge you to test the kernel as it is configured and just do "echo 100 > /sys/devices/system/cpu/intel_pstate/min_perf_pct" as root, runs really well here on my i7-2600k test system. Max kernel scheduling latency after 15 hours testing ranging from idle to a loadavg of 170 (on a 4 core cpu) is a whopping 41usecs... Seems to give very good scheduling latency and good powersave, so really the best of two worlds. One note in this context, I've noticed that I have to disable hyperthreading on this cpu too, not that it really showed any effect on scheduling latency, but I'd get xruns in my audio due to invalid cpu caches when the system was put under load. Your comment about nvidia makes me curious. I also have a gtx 750Ti card, and it hangs the gpu when for instance I try to watch a video on the -rt kernel. On the distro kernel it has no such problem. I have an older 8600gts card that works fine with -rt. Really will have to investigate this when I get some time. I suppose you did nothing special when building the nvidia-rt driver?

djimenez commented on 2014-07-09 03:22 (UTC)

By switching off pstate in the config.x86_64 file I've managed to get the performance governor as the default, which runs my system at the max 3.2GHz that it's capable of. This is on a Haswell Pentium G3420. The Nvidia graphics card also works flawlessly after two days of testing with the nvidia-rt drivers. This is a very recent model, too: GTX 750 Ti (maxwell). Thanks for all the effort! Daniel

Morgan_Cox commented on 2014-07-08 20:11 (UTC)

Some potentially bad news on rt kernel development - No new features, I'm rather pondering to drop stuff for 3.16-rt which is not absolutely required for basic operation just to make my life easier. - No massive effort to bring preempt-RT upstream After my last talk about the state of preempt-RT at LinuxCon Japan, Linus told me: "That was far more depressing than I feared".

jhernberg commented on 2014-07-07 08:03 (UTC)

I think the fact that you can't change the governor on the rt kernel is a bug, but no one has tracked that one down yet.

jhernberg commented on 2014-07-07 08:01 (UTC)

I've noticed the same thing on my i7 systems, but have started doing # "echo 100 > /sys/devices/system/cpu/intel_pstate/min_perf_pct" which seems to work fine. pstate still reduces the multiplier somewhat when idle, and lets the cpu go deep into C states, but once you start using CPU it seems to run at more or less max multiplier. Idling cpu temps seem similar to powersave, so I think this gives the best of both worlds at the moment. Another possibility is to make a small utility that opens /dev/cpu_dma_latency and writes 0 to it. If you get rt-tests from aur or the archaudio-production repo, you can run cyclictest as root to achieve this effect. It will disable powersaving of the cpu and run it flat out.

djimenez commented on 2014-07-07 04:47 (UTC)

ok, thanks a lot for your comments, I got it working now with the nvidia-rt package,too.. will report about the stability in a day or so. I noticed that trying to change the frequency governor as I used to wouldn't work in the rt kernel (sudo cpupower frequency-set --governor performance) so I set this in the config # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_GOV_COMMON=y CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y I intend to use this rt-kernel-setup only for audio, so leaving only the performance governor seems ok.. is this, in fact, the correct way to set this up? Daniel

jhernberg commented on 2014-07-06 12:01 (UTC)

@ djimenez: I mean your "non standard" way of building linux-rt.

jhernberg commented on 2014-07-06 11:59 (UTC)

@ djimenez: Another observation is that Archlinux patches the kernel to keep out of tree built kernel modules in directories named similar to extramodules-3.14-rt, so quite possibly your "non standard" way of building nvidia-rt got bit by the error in the kernel version number. I think if you do makepkg -cfi in the linux-rt package build directory, and then do the same in the nvidia-rt directory, it ought to build and install fine for you.

jhernberg commented on 2014-07-06 11:46 (UTC)

To follow up, I booted the 3.14.3-rt5-1 kernel today, with nvidia-rt 337.25-1. It did boot up fine, but as always it hung a bit later when playing video. I've mentioned this before and I think it's nvidia chip dependent. That is to say older cards work for me, but newer cards always hangs my system. Don't know if this is a general problem, or something specific to my system. The other observervation I can offer is that upstream made a mistake with the rt patch, and that this kernel actually identifies itself as 3.14.3-rt4-1-rt, but that didn't seem to have any impact on building and installing the kernel and nvidia-rt.

jhernberg commented on 2014-07-05 20:44 (UTC)

@djimenez: I don't know what went wrong for you? I just installed the the linux-rt and the linux-rt-headers package. After that I built and installed the nvidia-rt package from aur, and it worked just fine. If you use makepkg, try makepkg -cfi in the linux-rt source directory, that will build, cleanup and install the 3 packages in the build.

djimenez commented on 2014-07-05 04:42 (UTC)

After some messing around the PKGBUILD i got the installation to work. I had to add the line KARCH=x86 at the start of the package_linux-rt-headers() function, or else it would fail to copy a file some lines below. This may be a bug, though I'm not really sure. The compilation went smooth with that line in place (makepkg --pkg linux-rt-headers) and then I ran "makepkg --pkg linux-rt-headers -i" which installed the headers successfully. Now, I tried compiling and installing 'nvidia-rt' which fails after saying make[1]: *** /usr/lib/modules/3.14.3-rt4-1-rt/build: No such file or directory. Stop. It is true that there is no folder named like that, but why is the parent folder named 3.14.3-rt4-1-rt? shouldn't it be 3.14.3-rt5-1-rt as it is at the top of this webpage? Anyway, what's the recommended course of action here? I don't think I can get much farther on my own. Thanks again for all the hard work. Daniel

djimenez commented on 2014-07-05 02:50 (UTC)

I'm a bit confused, hopefully someone will be able to help me set this kernel up along with the nvidia-rt package. After installing this package with the pacaur helper, the installation attempt for nvidia-rt failed mentioning no source for the linux-rt-headers package. I understand that there are three packages as a part of this 'split package' but, what would be the standard way of installing the missing linux-rt-headers? Thanks for all the hard work. Daniel

jhernberg commented on 2014-06-20 18:37 (UTC)

Regarding linux-rt-lts I can confirm that it's broken now on intel gpus. I also get screen corruption on my 2 intel machines, it worked when I uploaded that kernel.. What is worse is that I've built 3.10.44-rt45 and it fails to boot on both of my test machines, think it's the efi boot problem that plagues some archlinux users:, but haven't had time to check that hypothesis yet. So really don't know if I should upload it or not :(

jhernberg commented on 2014-06-20 18:28 (UTC)

Hmm, where do I start? :) I personally have not noticed any problems with 3.14-rt on 2 machines. That said, at the moment I'm using high latency, so might not have noticed. cyclictest results are excellent, at least if massaging the intel pstate driver which appears to finally beginning to work as it's supposed to. Maybe this is the problem, as when the cpu runs slower processing audio will take longer time and will need more latency. You can try to run cyclictest as root, which will open (and keep open) /dev/cpu_dma_latency and write 0 into it, which serves to disable cpu powersave. A better solution might be to write 100 into /sys/devices/system/cpu/intel_pstate/min_perf_pct, which will make the cpu multiplier run much higher and the processor spend more time in c-states (my solution at the moment) as it seems to fix cyclictest max values and keep the cpu cool. Regarding wbinvdt(), afaik know that is only used on really old hardware, like chipsets older than 910, and intel pentium4 cpus, so don't think that is an issue at all (for most of us).

johannesgh commented on 2014-06-20 17:20 (UTC)

Just to reassert my lack of knowledge: I've been using Arch for less than a year, but I have some understanding of the system and a willingness to expand it. @david.runge: I have an Intel i5-4570 and am using the integrated graphics. In System Info (I'm using Cinnamon) it says: Graphics Card: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller. AND: $ pacman -Q | grep intel intel-dri 10.2.1-2 lib32-intel-dri 10.2.1-2 libva-intel-driver 1.3.2-1 xf86-video-intel 2.99.912-1 ... so I probably have i915 ? @Ninez: It wasn't an assumption, just a guess, but thank you for clarifying. Can you tell me where I can find instructions pertaining to the settings you were telling david about? I want to check if I can fix it that way, should the "Intel Graphics" Arch wiki site be enough to get me started or is there a better place to start?

jrdnjhntn commented on 2014-06-20 14:04 (UTC)

@david.runge - Are you using i915.do_wbinvd=no on your grub commandline + pinning any process doing gfx work to the same CPU core? [if not, that is probably part of your problem]. i915 has the same problem as the nvidia driver on RT. [can introduce lots of latency due to the wbinvdt() calls in the drivers]. @johannesgh - no. your assumption about the revert timer patch affecting rtirq is completely wrong. [that code has nothing to do with rtirq whatsoever, nor could it affect it. fyi, i wrote the patch / found the bogus commits that broke some AMD / ARM h/w from booting... and I use rtirq].

dvzrv commented on 2014-06-20 06:40 (UTC)

@johannesgh: are you using the i915 driver? I'm experiencing massive xruns and instability with and without rtirq.

johannesgh commented on 2014-06-19 23:44 (UTC)

@david.runge since I updated last week I've been having video problems with linux-rt-lts, so I got this one, and the video's fine but I have been getting a lot more Xruns even with double the latency ... I used to get them just when opening and closing Ardour and not at all otherwise, but now I get quite a lot of them. I was wondering if maybe one of the patches f's up the settings of the "rtirq" package, do you use that one as well? "revert_timers-dont_raise_softirq_unconditionally_and_fixes.patch" looks suspicious to me but I'm a noob.

dvzrv commented on 2014-06-19 16:57 (UTC)

@jhernberg: Hm, this one seems to be much more unstable than the 3.12 series. I get way more Xruns (even compared to vanilla kernel) on a setup I haven't changed in a while. Are you experiencing similar things?

jhernberg commented on 2014-05-30 12:06 (UTC)

Hmm, I just realized that cpupower frequency-set -g governor works on the vanilla kernel, and not on the -rt patched kernels. This has been like this for a while, I just didn't realize that it was only broken on -rt... Gonna see if I can get some more info on this problem.

jhernberg commented on 2014-05-30 11:26 (UTC)

@earn: But you still ought to be able to make the kernel run full throttle with a workaround. Run cyclictest as root in some window and see if that doesn't make the cpu run full out.

jhernberg commented on 2014-05-30 11:24 (UTC)

@earn: I've wondered for a long time why cpupower shows both powersave and performance, but won't me select performance. My guess was that it's a bug in the pstate driver, but if you say you have the same on AMD, then I suppose it's worthy of investigation...

jrdnjhntn commented on 2014-05-29 11:49 (UTC)

@earn - yeah, i see. Yeah, i was confused when you first said your phenom wouldn't boot with revert_timers-dont_raise_softirq_unconditionally_and_fixes.patch [as that makes most AMDs boot fine]... anyway, as a workaround you could use my kernel [or recompile linux-rt with 'perforamnce' governor or 'userspace' as default]. it's a bit of a hassle, but at least the default governor [at compile time] works...and yes, known bug for sure - with patches on LKML to fix it ;) as far lpa options; UKSM - in kernel memory-deduplication BFQ io scheduler is available [at runtime] gcc cpu optimizations available for kernel [ -march=native by default ] option to bring back sirqs [splitting of softirqs on -rt] + a few other bits, like an optimization to idle_balance, linux' max_readahead, plus the previously mentioned fixes.

commented on 2014-05-29 11:35 (UTC)

Ninez: I'm sorry, I wasn't very clear. The linux-rt from AUR is booting fine, but you can not set the governor to Performance (even if it's listed as available by frequency-info), nor change options in /etc/default/cpupower to use cpupower as a service. It just doesn't work. I search and apparently it's a known bug, the governor must be choosen at the compilation stage. I didn't try your kernel, what are those L_PA options ? I will try it anyway right now !

jrdnjhntn commented on 2014-05-29 11:19 (UTC)

@earn - just to clarify; 1st you said that neither linux-rt nor linux-rt-lts would boot for you - is this correct? ...meaning that when you say "the rt kernel boots fine", you are talking about my rt kernel? [ie: the binaries that i posted?] ... [maybe posting the output of 'uname -a' would help with clarification]. as far as cpufreq - as i said below; it's not working correctly for some CPUs on 3.14 - so if it is linux-l-pa that you are running/actually booted - then you are using userspace governor [since only the 'default' will work correctly]. userspace governor is controlled like so; 1. sudo cpupower frequency-info [to see what cpufreq's are available] 2. sudo cpupower frequency-set -f 3.4GHz [in my case, 3.4GHZ is my top cpu frequency]. I am hoping tonight or tomorrow that i am able to test/apply some patches that _should_ fix cpufreq/acpi/allow everything to work again - bt I've just been a bit busy with work, the last few days.

commented on 2014-05-29 09:58 (UTC)

Ninez: Thank you a lot for your answers and the time spent to write them ;) So the RT kernel boots fine, but the LTS doesn't. Anyway, I can't get to put my CPUs on Performance, using cpupower "frequency-set -g performance". Do you have a solution to resolve this issue ?

jrdnjhntn commented on 2014-05-26 19:56 (UTC)

I ended up building some generic x86_64 binary packages for linux-l-pa [for one of my users and anyone here who is having problems / wants to see if the fixes/patches [mentioned below] help their instability or booting problems. linux-rt and linux-l-pa are fairly similar, as, most of my additional features are not enabled by default. [there are some differences, but for this testing purpose, the smaller stuff shouldn't matter all that much]. The big differences are linux version [3.14.4-rt5] and the 4 fixes/patches [in below comment] and my backport_pm_acpi_4_3.15-rc6.patch - which at least settles down most of the acpi breakage [on my H/w anyway.]. the USERSPACE cpu governor is also default in linux-l-pa since switching governors and some sysfs stuff still is somewhat broken for myself/some of my users on 3.14 [on my AMD's...sigh], but works fine on my Intel machine. [wtf?] Anyway, it would be nice to know if the 4 patches mentioned b4, help anyone - as they certainly helped a user of mine, big time with instability/crashing/etc and on my one machine; devices which b4 never worked correctly when sharing interrupts -> work just fine now :) [my wacom used to get disconnected sometimes, if on a shared interrupt line. super annoying. spurious irq patch fixes that.] note: linux-l-pa/AUR has nvidia-l-pa package, as well. if a tester needs it; and again, let us know, if there are any differences on your system; like stability improvements or actually being able to boot. [@earn - i feel your pain, i wasn't able to boot on newer kernels, until recently...obviously, there is still some ugly/lerking bugs]..cheerz

jrdnjhntn commented on 2014-05-26 14:44 (UTC)

@earn - Could you please try debugging boot? ... then you could post/link to pastebin. - i am more than willing to have a look. the revert_timers-dont_raise_softirq_unconditionally_and_fixes.patch _should_ have fixed the boot problems for phenom [you are the 1st that i have heard otherwise.]. That being said though; 3.14 has some issues [so does Arch's kernel for that matter]...With my own rt kernel [linux-l-pa;] I have had to backport patches from -tip to fix mainline and RT problems, some of which are fairly serious problems [although not always obvious]; the deadlock detection code is broken, spurious irq detection broken, potential race in wait_for_completions [simple wait code] and acpi/cpufreq for the matter is horribly broken on 3.14.3 for some users, including myself :\ that's why, in part, linux-l-pa is 3.14.4-rt5 + patches/backports and NOT 3.14.3-rt5]...All of these problems are known about and are being dealt with upstream. @smoge - what sort of instability/symptoms are you experiencing? I do like your idea of uploading some test binaries, if you guys like; i could provide linux-lpa generic x86_64 binraries? [***which will not remove linux-rt]. My rt branch has some addition patches -> Maybe people with unstable systems can test them out, and let jh and i know if it helps? ... I have 4 particular patches applied that may make all of the world of difference, in terms of stability on 3.14-rt; [and this is for your eyes, jh!] genirq-Sanitize_spurious_interrupt_detection_of_threaded_irqs.patch rtmutex-Handle_when_top_lock_owner_changes.patch drivers-serial-call-flush_to_ldisc-when-the-irq-is-t.patch fix-race-in-PRT-wait-for-completion-simple-wait-code_Nvidia-RT.patch I would say having working deadlock detection, spurious irq detection and fixing a race [condition] in the simple wait code is fairly important stuff. ;) anyway, if you guys [with issues] would like me to compile some generic x86_64 binaries to test - please let me know. [i could do that in an hour or so]

smoge commented on 2014-05-26 13:57 (UTC)

@jhernberg: thank you for the work, but please let's keep the rt-lts as stable as possible... I miss the time of 3.0-rt, my system hasn't been that stable since then. I would avoid beta/testing quality kernels, but someone could upload a testing binary somewhere, why not.

commented on 2014-05-26 13:23 (UTC)

Hi guys, I can't boot on either this or the lts RT kernel. I have a Phenom, is it still related ? Thanks for your help !

jhernberg commented on 2014-05-26 12:52 (UTC)

@blackhole: I don't see any substantial difference between the kernels, all show a max kernel scheduling latency of 0.03ms or lower, so I don't think the scheduling will be an issue with any of them. Mind you, I don't know what kind of hardware you have, but a loadavg of around 1 isn't all that high if you have a smp system. Try running hackbench -l 100000 or something like that, which will really load down the system.

blackhole commented on 2014-05-26 12:15 (UTC)

test result KERNEL linux-rt-3.12.15_rt25-2 arch-production --> Jriver 192 upsample + equalization ./cyclictest -n -m -Sp98 -i100 -d0 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 1.10 1.05 0.68 2/317 13898 T: 0 (13530) P:98 I:100 C: 293490 Min: 2 Act: 5 Avg: 3 Max: 20 T: 1 (13531) P:98 I:100 C: 294532 Min: 2 Act: 5 Avg: 5 Max: 30 T: 2 (13532) P:98 I:100 C: 294481 Min: 3 Act: 5 Avg: 5 Max: 29 T: 3 (13533) P:98 I:100 C: 294430 Min: 3 Act: 7 Avg: 5 Max: 27 ___________________________________________________ KERNEL 3.14.3-rt4-1-rt arch-production --> Jriver 192 upsample + equalization ./cyclictest -n -m -Sp98 -i100 -d0 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 1.16 0.67 0.27 2/303 1612 T: 0 ( 1606) P:98 I:100 C: 200421 Min: 1 Act: 3 Avg: 2 Max: 14 T: 1 ( 1607) P:98 I:100 C: 200379 Min: 1 Act: 3 Avg: 2 Max: 17 T: 2 ( 1608) P:98 I:100 C: 200337 Min: 2 Act: 8 Avg: 2 Max: 25 T: 3 ( 1609) P:98 I:100 C: 200295 Min: 2 Act: 3 Avg: 2 Max: 15 --> mpd low latency 192 KHz upsample sox ./cyclictest -n -m -Sp98 -i100 -d0 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.41 0.64 0.37 1/295 1955 T: 0 ( 1927) P:98 I:100 C: 181698 Min: 1 Act: 3 Avg: 2 Max: 14 T: 1 ( 1928) P:98 I:100 C: 181655 Min: 2 Act: 2 Avg: 2 Max: 15 T: 2 ( 1929) P:98 I:100 C: 181597 Min: 1 Act: 2 Avg: 2 Max: 22 T: 3 ( 1930) P:98 I:100 C: 181559 Min: 1 Act: 3 Avg: 2 Max: 15

jhernberg commented on 2014-05-26 11:52 (UTC)

@blackhole: The only way to install 3.12-rt now that the linux-rt has moved to 3.14-rt would be to edit the buildscript and install it yourself. Been thinking of maintaining linux-rt, linux-rt-lts and linux-rt-testing, but that would be increased work to keep track of, and I really don't think that we are so many users that it's warranted... Especially since linux-rt-lts doesn't seem to actually be used... I might however move linux-rt-lts to 3.12-rt, still thinking about that one though...

blackhole commented on 2014-05-26 11:13 (UTC)

Ok. Is there a way to install linux-rt 3.14.3_rt5-1 and keep the older realtime kernel?

jhernberg commented on 2014-05-24 16:47 (UTC)

@blackhole: It's the same kernel as in archaudio-production. I maintain both of them. Sorry to hear about shutdown, any more details? I guess I should state that this kernel is really to regard as beta quality, because it's where new development is taking place, so it's reasonable to expect bumps in the road. For a production system, linux-rt-lts would really be preferable, as it's meant to be as bug free and stable as possible. Regarding latency, can you substantiate it somehow? Maybe run (sudo) "cyclictest -n -m -Sp98 -i100 -d0" and note down the max values after putting the system under load and running it for a while. cyclictest can be found in the rt-tests package, also both on aur and on archaudio production. running it as root might give better results, as it tries to disable powersaving. The result is an approximation of the maximum kernel thread scheduling latency in microseconds, and is a good test of how well the rt patched kernel is running.

blackhole commented on 2014-05-24 15:25 (UTC)

I am not sure if this is the same as in archaudio-production. If yes, shutdown will always hang in my system. Moreover it seems that it is not performing as good as 3.12.15_rt25-2 for latency.

jhernberg commented on 2014-05-18 14:20 (UTC)

Maybe I should clarify.. At first glance NO_HZ/FULL/IDLE appeared to work fine on my system, but after pounding it, various issues popped up, so I think all in all it is a better choice at this moment, just to disable all of it.

jhernberg commented on 2014-05-18 14:13 (UTC)

OK, finally found some time to work on this again. I reverted the 3 patches as per Ninez recommendation, I also disabled all NO_HZ functionality. Kernel appears to work fine on my machines, and hopefully on all others. I also had a load of strange occurrences with NO_HZ on my system, so NO_HZ appears to have problems so far on 3.14-rt. I'll keep trying NO_HZ on my own machines as new -rt patches come out, and hopefully the AMD problem can be worked out by someone with access to such a system. @Ninez: So far I haven't had any time to mess around with /dev/cpu_dma_latency, hopefully one day I'll get time to look into it. At the moment I just use cyclictest to make it run with no powersaving when I need it :) But all in all Intel's pstate seems to work really well on 3.14.

jrdnjhntn commented on 2014-05-12 02:22 (UTC)

@jhernberg - nope. still hangs without reverting those patches on vanilla-rt. NO_HZ_FULL seems to be okay [when, i have a bootable config], bkernel] but then again, I wasn't the one who was getting instability with it [another user did. periodic timers fixed everything] so NOHZ working for me, doesn't exactly say much - that being said, i am building him various binaries to test. so probably tomorrow/next day i'll get some feedback on that. more on PMQoS; you're aware / have used the tool 'tuned' before, produced by redhat?? [it's in AUR;]. it plays with /dev/cpu_dma_latency [among other things].. tuned has various profiles that you can choose from. the latency-performance sets cpu_dma_latency to zero, IIRC.

jrdnjhntn commented on 2014-05-11 02:46 (UTC)

@jhernberg - I am running 3.14.3-rt5 but patched.. however, I'm build several kernel configurations, now. [** vanilla 3.14.3-rt5 + no_hz_full & -rt5 with periodic ticks... I also am building [generic] binaries of linux-l-pa in a couple of configurations, for unrelated test/with another user]... So, i should have feedback on vanilla -rt tomorrow [it's getting late here]. Hopefully, the work done on -rt5 has fixed a few things... Obviously, nvidia is fixed / i know no one was being 'sinister' it's just annoying, more than anything ;) Regarding pmqos [/dev/cpu_dma_latency]. I'd point you to documentation, but i am sure you have seen it via google. I use that interface on a device to limit c-states / reduce possible impacts/spikes in latency [at the cost of more power consumption + heat]. I suppose you could implement it in wineASIO to set it to a low[est] state before processing, than higher/deeper state, when not processing/active. though, user-defined would probably be a necessity, as that is a 'global' system/kernel tunable, thus may impact other applications, no? It's an interesting idea, anyway. so i will get back to you tomorrow on how vanilla-rt went.

jhernberg commented on 2014-05-10 16:28 (UTC)

@Ninez: Regarding the turbo, I think this is perfectly reasonable behavior. After all, if p and c states are working as they should, when the load isn't high it will throttle the cpu, and a slower cpu will take longer to finish the same work load. There is an interface to control this somewhat in /dev/cpu_dma_latency, and once I understand it better I might add user configurable control of it to wineasio.

jhernberg commented on 2014-05-10 16:21 (UTC)

@Ninez: I meant that I disabled NO_HZ_FULL/IDLE, and applied your patch. That said 3.14.3-rt5 seems to run wonderfully well here with NO_HZ_FULL/IDLE enabled and no patch reverted... How are things on your end? I take it that the nvidia trouble is fixed. How are your troublesome AMD systems doing? The reason for the GPL problem is that when that function was first submitted it was exported as GPL. The maintainer of the 3.14-rt patch simply forgot to change it when he made the first 3.14-rt series patch. No sinister motives, just one of those things that can happen. After testing for about 20 hours now, both under load and idle, nothing has exploded, so I'd say this patch is good to go. Just wanna know how your amd cpus are working. Would be somewhat a shame to disable dynticks, but I guess if that is what it takes to make it work for everyone...

jrdnjhntn commented on 2014-05-07 23:19 (UTC)

@jhernberg - ah i see [about turbo]. it would seem upstream pulled the carpet from underneath your feet ;) 3.14 seems to come with 'hackery' or adjustments required, depending on use. i gather from "So far the kernel seems to work quite well like this." - you mean you tried out revert_timers-dont_raise_softirq_unconditionally_and_fixes.patch && switched to periodic ticks? If so, I am not surprised that it's working better. [as i said before, i think those patches do some weird stuff to the rt timer code.]... and obviously, i have been reverting that stuff for a while now. [but only switched back to Periodic ticks on 3.14-rt]. I'll be curious to hear how it works, as you test/stress it more. I think as 'default' PREEMPT_RT_FULL config; avoiding NOHZ for now, might be a good idea, especially on 3.14-rt. the 'nvidia problem' is pretty minor really. [but i appreciate you chipping/chiming in on that, very helpful man!]. Det suggested to me, that i just detect if nvidia package or nvidia-settings is installed to workaround the problem for packaging. Which i've found to be an easy workaround for now. [no user intervention, only modifies __rt_mutex_init on nvidia systems, at compilation time... Fairly seamless]. What i find funny though, is that it wasn't all that long ago, when the same thing happened. Not only that, but making that a gpl-only symbol seems like overkill - especially, since it disallows modules that are intended to be GPL-compatible modules [MIT,etc] from accessing __rt_mutex_init. anyway, let me know how things go...

jhernberg commented on 2014-05-07 22:18 (UTC)

@Ninez: Seems that my cpu doesn't use any turbo multiplier any more when running that project, when I started a compile and forced it into turbo mode, then my monitors reports the same cpu use that it used to do for that project. So far the kernel seems to work quite well like this. Pity about the nvidia problem though...:(

jrdnjhntn commented on 2014-05-07 18:32 (UTC)

@jhernberg - you got it; that is the correct patch. basically, just apply after applying the full rt patch and you're good to go. Yeah, if you are experiencing any weirdness, it could be due to dynticks. I got sick of messing with nohz, periodic timers are 'proven' so to speak. I would say definitely give it a try and see what happens. btw; could your reaper + linux-rt 3.14 performance problem have anything to do with this; ... maybe your problem is related?

jhernberg commented on 2014-05-07 18:00 (UTC)

@Ninez: Is this the patch to revert the 3 original patches? revert_timers-dont_raise_softirq_unconditionally_and_fixes.patch

jhernberg commented on 2014-05-07 17:58 (UTC)

@Ninez: I saw your email, but sometimes cc to the right people or irc can do wonders :) I had a small blowup today on 3.14.2-rt3, definitively not ready for prime time, at least with NOHZ :) I'll have a look at reverting the 3 patches and disabling dynticks. Maybe that's more stable. No need to waste time on reaper, I have 3.10-rt and 3.12-rt a boot away, so it's just a matter of rebooting and noting how the project behaves there. Maybe I did something stupid :)

jrdnjhntn commented on 2014-05-07 13:53 (UTC)

@jhernberg. Good, on the __rt_mutex_init issue - although, i must say, it was reported weeks ago. [i brought it up 3rd week of april on the list]. Regardless, it's good they plan on doing something [finally]... Regarding 'AMD issue' -it's not just an AMD issue, reverting those patches allowed an ARM board to boot / work correctly too [which was also brought up on the list;]... but to answer your question; Yes, Reverting the patches is required in order to be able to boot any -rt kernel post-3.12.x-rt9 ... But i also have switched to periodic timers [old tick in kconfig] for a couple of reasons. 1). The NO_HZ_* stuff seems a bit dicey [i know of a machine that exhibits odd behavior if using it, but works fine without], 2). Since, i am dropping those fixes, it makes sense to drop no_hz_* from kconfig [thus, no more 'NOHZ: pending stuff] and stick with periodic timers. regarding reaper - I could probably have a look at that, in the next few days - I have kernel binaries dating quite far back [so easy testing]. I haven't used Reaper much lately [been too busy], but I'll free up sometime to have a look, as that concerns me.

jhernberg commented on 2014-05-07 09:10 (UTC)

@Ninez: I just chatted a bit with rt devs, and the EXPORT_SYMBOL_GPL(__rt_mutex_init); issue is now on the list, and will be fixed for the next rt patch sometime next week. Regarding the AMD issue they can't do much more than speculate without more hard information as no one seems to have such a cpu available to test on. So you have to revert the 3 patches and turn off NO_HZ_FULL, or do you have to turn off NO_HZ completely? The issue I need to study is that I think with 3.14 vs earlier -rt kernels, reaper+vst is using more cpu and produces a higher "dsp load" on the same project.

jrdnjhntn commented on 2014-05-07 08:11 (UTC)

@jhernberg - just to verify, -rt3 seems fine. [well, with usual patching]. But i will build linux-rt overnight to test 'vanilla'. btw, i meant to ask - what issues/problems are you having/puzzled by?

jrdnjhntn commented on 2014-05-07 07:41 (UTC)

@jhernberg - well, 3.14.2-rt3 i have just built [haven't rebooted yet]. It will probably run just fine with how i have it configured [ie: with those 3 patches removed, plus, the other usual bits that i add/change]... [I'm not expecting any real breakage between 3.14.1-rt2 and -rt3]. as far as AMD problem. No, not fixed. One guy on RT list got his to boot, but no one else reported back success and mine still doesn't boot. [thus, i remove said patches and it works fine... i also disable NO_HZ_FULL, obviously.]. as far as nvidia, i just do; if [ -f /usr/bin/nvidia-settings ]; then sed -i 's/EXPORT_SYMBOL_GPL(__rt_mutex_init);/EXPORT_SYMBOL(__rt_mutex_init);/' "${srcdir}/linux-3.14/kernel/locking/rtmutex.c" fi my PKGBUILD, which takes care of nvidia users. Yeah, it should be fixed upstream and [as you probably know] I mentioned on rt list [which was also CC'd to other lists; LKML, etc ] + I notified nvidia at the time... not else much for me to do about it, beyond providing a workaround for packaging ;) ...but i agree, having to use a hack is annoying. I am annoyed the symbol was changed, when we already went through this, not all that long ago.

jhernberg commented on 2014-05-07 07:08 (UTC)

@Ninez: how are you doing with 3.14.2-rt3? Did you get your AMD problem fixed? After creating a patch I have successfully built and am running 3.14.2-rt3 right now. so far without any big issues, though i'm a little puzzled by something on my system that needs more testing. I note that the nvidia problem still is present too :S Would like to get it out, but am not sure about the above 2-3 issues or if I should wait. Think I came up with the nvidia hack back then, but modifying the license of someone else's software is kind of a nasty hack (be it the kernel or the closed nvidia driver)...:) Would be far better if that was fixed upstream...

jrdnjhntn commented on 2014-04-15 15:19 (UTC)

@jhernberg - I haven't heard anything back [from rt-devs] on those 3 patches - reverting them does allow all of my machines to boot [Intel/AMD]. So I've ditched those patches, since having the non-fatal; NOHZ: local_softirq_pending 40 is better than having machines that won't boot ;) [my uptime is 2 days on one machine, that has been tortured via hackbench ... while the others I've rebooted a few times, to test revisions, nvidia, etc]. i did also notify nvidia; and may still yet hit LKML about the EXPORT_SYMBOL_GPL issue. So until that is sorted, i brought back the old hack from 3.0-rt PKGBUILD, when we faced almost the exact same issue; # sed -i \ # 's/EXPORT_SYMBOL_GPL(__rt_mutex_init);/EXPORT_SYMBOL(__rt_mutex_init);/' \ # "${srcdir}/linux-3.14/kernel/locking/rtmutex.c" ...then, nvidia users can uncomment that themselves before compilation and nvidia binary module will compile/load/work fine... I would assume a similar approach would work for you, until something upstream happens... cheerz

jrdnjhntn commented on 2014-04-13 16:05 (UTC)

@jhernberg - just an update on the AMD booting problems; 3.14-rt is bootable / stable on my machines by reverting 3 linux-rt patches; | timers-do-not-raise-softirq-unconditionally.patch | timer-Raise-softirq-if-there-s-irq_work.patch | timer-rt-Always-raise-the-softirq-if-there-s-irq_wor.patch I've had 3.14 running for acouple of hours now :) - I've also hit the list and clarified a few things, regarding this - hopefully, Sebastian/thomas can have a closer look at those patches and see if we can get a proper fix / revision that works for everybody / doesn't hose some AMD machines. 2. I don't know if you have noticed yet, but linux-devs decided to mark __rt_mutex_init as EXPORT_SYMBOL_GPL [even though it never has been a gpl symbol and is used by nvidia / possibly others, which require EXPORT_SYMBOL]. I've gone ahead and pointed this out on the list too. I also have a patch for the 337.xx nvidia beta to change the license of both modules, shipped by nvidia;]. anyway, aside from these hassles 3.14-rt seems decent. Hopefully, we can get the boot failures work out for 3.14.x-rt.

totalchaos commented on 2014-03-30 19:27 (UTC)

@daniel.appelt That was it. Thanks :)

daniel.appelt commented on 2014-03-30 14:01 (UTC)

@totalchaos: you are maybe missing the patch package which is part of the base-devel group:

totalchaos commented on 2014-03-29 21:03 (UTC)

Both linux-rt and linux-rt-lts are not installable :( Here is some of the terminal output: ==> Continue building linux-rt ? [Y/n] ==> ---------------------------------- ==> ==> Building and installing package ==> Making package: linux-rt 3.12.14_rt23-1 (Sat Mar 29 22:40:05 EET 2014) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Downloading linux-3.12.tar.xz... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 72.8M 100 72.8M 0 0 3101k 0 0:00:24 0:00:24 --:--:-- 3505k -> Downloading patch-3.12.14.xz... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 369k 100 369k 0 0 185k 0 0:00:01 0:00:01 --:--:-- 185k -> Downloading patch-3.12.14-rt23.patch.xz... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 142k 100 142k 0 0 98k 0 0:00:01 0:00:01 --:--:-- 98k -> Found config -> Found config.x86_64 -> Found linux-rt.preset -> Found change-default-console-loglevel.patch -> Found criu-no-expert.patch -> Found sunrpc-create-a-new-dummy-pipe-for-gssd-to-hold-open.patch -> Found sunrpc-replace-gssd_running-with-more-reliable-check.patch -> Found nfs-check-gssd-running-before-krb5i-auth.patch -> Found rpc_pipe-remove-the-clntXX-dir-if-creating-the-pipe-fails.patch -> Found sunrpc-add-an-info-file-for-the-dummy-gssd-pipe.patch -> Found rpc_pipe-fix-cleanup-of-dummy-gssd-directory-when-notification-fails.patch ==> Validating source files with md5sums... linux-3.12.tar.xz ... Passed patch-3.12.14.xz ... Passed patch-3.12.14-rt23.patch.xz ... Passed config ... Passed config.x86_64 ... Passed linux-rt.preset ... Passed change-default-console-loglevel.patch ... Passed criu-no-expert.patch ... Passed sunrpc-create-a-new-dummy-pipe-for-gssd-to-hold-open.patch ... Passed sunrpc-replace-gssd_running-with-more-reliable-check.patch ... Passed nfs-check-gssd-running-before-krb5i-auth.patch ... Passed rpc_pipe-remove-the-clntXX-dir-if-creating-the-pipe-fails.patch ... Passed sunrpc-add-an-info-file-for-the-dummy-gssd-pipe.patch ... Passed rpc_pipe-fix-cleanup-of-dummy-gssd-directory-when-notification-fails.patch ... Passed ==> Extracting sources... -> Extracting linux-3.12.tar.xz with bsdtar -> Extracting patch-3.12.14.xz with xz -> Extracting patch-3.12.14-rt23.patch.xz with xz ==> Starting prepare()... ==> apply patch-3.12.14 /tmp/yaourt-tmp-biser/aur-linux-rt/./PKGBUILD: line 58: patch: command not found ==> ERROR: A failure occurred in prepare(). Aborting... ==> ERROR: Makepkg was unable to build linux-rt. ==> Restart building linux-rt ? [y/N] ==> --------------------------------- ==>

Det commented on 2014-03-18 14:49 (UTC)


jhernberg commented on 2014-03-11 23:05 (UTC)


Det commented on 2014-03-11 20:09 (UTC)

What is that question?

mindhack commented on 2014-03-06 18:57 (UTC)

Is there a list with the configuration differences against the [core] kernel? Thanks!

jrdnjhntn commented on 2014-03-02 23:10 (UTC)

@jhernberg - not really, the git-bisect revealed nothing (my own fault, as -rt8 does boot for me, but i've experienced 2 deadlocks on that kernel). -rt9 is the problem and i doubt it is a mainline problem... afaict, the fixes for some i7 machines cause regressions for some AMD users. [those three patches/fixes are junk as far as i am concerned... they weren't tested thoroughly on common H/w before being commited - breaking -rt for a bunch of people]. ie: Phenom is not the only CPU affected. Mike Galbraith pointed out an AMD CPU that failed for him. Kimmo today piped in on my thread on rt list and mentioned not only Phenom but also Turon as failing to boot, Pavel also piped in [although, he wasn't very specific]. So it's a subset of AMD cpus that fail, in order to fix a few i7 machines. super annoying... anyway, I am going to take another stab at it tonight, then hopefully i will have something to bring back to the rt list for discussion. I think the safe bet, is to continue to recommend -rt-lts (3.10.x-rt) or -l-pa (3.12.5-rt7 aka: the last solid -rt release for that subset of AMD users, like myself, unknown78, etc).

jhernberg commented on 2014-02-25 13:09 (UTC)

@Ninez, any news on the AMD Phenom II 965 x4 issue?

jhernberg commented on 2014-02-18 19:30 (UTC)

Hehe, I try to test it for serious problems before I upload it, after all it's a kernel and not just some app... Was also hoping for some news about the AMD Phenom II 965 x4 problem ;)

sekret commented on 2014-02-18 17:57 (UTC)

Those lines need to be updated: _releasever=11 _rtpatchver=rt17 md5sums=('cc6ee608854e0da4b64f6c1ff8b6398c' '11ecacf1f22d057c92dcb93f1df71ff9' '5c46965799741357e7a48c2c32735929' '38567cec912f1e0db6c8417916bdd1e6' '97de19de5c3632988f3e6adaf9d8fad2' 'eb14dcfd80c00852ef81ded6e826826a' '98beb36f9b8cf16e58de2483ea9985e3' 'd50c1ac47394e9aec637002ef3392bd1' 'd4a75f77e6bd5d700dcd534cd5f0dfce' 'dc86fdc37615c97f03c1e0c31b7b833a' '88eef9d3b5012ef7e82af1af8cc4e517' 'cec0bb8981936eab2943b2009b7a6fff' '88d9cddf9e0050a76ec4674f264fb2a1' 'cb9016630212ef07b168892fbcfd4e5d')

Xemertix commented on 2014-02-18 09:02 (UTC)

rt17 out

jrdnjhntn commented on 2014-02-12 14:43 (UTC)

@jhernberg - nah, i wouldn't bother doing that - the problem needs to be fixed upstream and while reverting those patches does boot [at leat on -rt11] it was quite unstable. [I think for those suffering the suggestion of using linux-rt-lts is a good choice]. I am hoping for some time tonight to do a bisect, if not - i still expect in the next day or two - to get around to it, for sure ;) ... I've just been insanely busy, otherwise it would already be done/found.

jhernberg commented on 2014-02-12 07:48 (UTC)

@Ninez: Correct me if I'm wrong.. Reverting the 3 mentioned patches won't fix/work around the problem on AMD Phenom II 965 x4? Otherwise I'd upload a package build with them reverted.

jrdnjhntn commented on 2014-02-11 15:56 (UTC)

Sebastian [linux-rt user list] thinks it is a mainline commit, not -rt specific that is causing the boot failures on -rt. [no -rt specific changes between -rt7 and -rt8 => -rt7 works perfectly, -rt8 fails to boot... which only leaves a mainline commit as the source of the problem. I gotta free up some time, first - but I'll do git-bisect to find the bad commit. [well, first i will have a look at commits between those mainline releases to see if anything pops out, that i could quickly test before doing a full bisect].

jrdnjhntn commented on 2014-02-11 15:19 (UTC)

@jhernberg - nope. -rt15 fails to boot. I've run out-of-time to test reverting the 3 patches that Sebastian suggested on the linux-rt user list && I have already posted to the list about -rt15 failing.... Unfortunately, his suggestion of reverting those patches doesn't really solve the problem [at least not for packaging purposes]... @vvd - i would be curious if you experience the same failure on -rt15, if you are able to test, let us know the results [but i assume you will see the same failure, as before].

jrdnjhntn commented on 2014-02-11 12:38 (UTC)

@Jhernberg - I've got the morning off of work, it's 7:30am. I'm grabbing some coffee, then I will start -rt15 compile/install. I'll get back to you when it finishes / i try booting.

jhernberg commented on 2014-02-11 08:10 (UTC)

Does 3.12.10-rt15 work for you guys having problems on AMD Phenom II 965 x4 cpus? Anyone else have the same problem, but on another cpu?

jhernberg commented on 2014-02-06 10:25 (UTC)

Yeah, linux-rt-lts is what I'd actually recommend everyone to be running, seeing that the latest -rt patches are tests of new stuff, and could break something at any moment. For lts-rt, I try to keep the same config as the distro -ARCH kernel, and the -rt patchset is to be regarded as mostly stable. Looking forwards to see what the mailing list has to say about this problem, if there is a patch and confirmation that it works, I'll apply it straight away.

vvd commented on 2014-02-06 10:05 (UTC)

Thanks Ninez! I'll try your l-pa kernel. Looks interesting.

jrdnjhntn commented on 2014-02-06 02:08 (UTC)

@Det - yeah, -rt13 is also bunk. I am holding off on updating my own packages, since the last few RT releases are quite unreliable for a lot of users. -rt7 was the last good release, imho. @vvd && Jhernberg - I just hit the linux-rt user list to share my boot failures (since we have the same CPU hopefully, i will get some follow up, suggestions + maybe test a patch or something like that for the linux-rt developers. ~ Until we get a solution, you (vvd) have two options; a) use Jhernberg's linux-rt-lts (which i believe is 3.10.x-rt) b) use my linux-l-pa package in AUR, which is the last usable release with our CPU. [however, note: my kernel has other out-of-tree linux features; BFQ, UKSM, as well as a few bits pulled from linux 3.13]. - these may or may not be features that you are interested, regardless, you can disable them during runtime, if you don't want them. cheerz

vvd commented on 2014-02-05 19:43 (UTC)

I am having the same problem as Ninez has. This does not boot. I am also running an AMD Phenom II 965 x4.

Det commented on 2014-02-04 12:20 (UTC)

Hmm.. -rt13 is up.

jrdnjhntn commented on 2014-02-01 12:35 (UTC)

@jh - yeah, I know (it's annoying). I knew to revert the timers-do-not-raise-softirq-unconditionally.patch, due to your packaging of -rt8.(but obviously on -rt9, you must also revert timer-Raise-softirq-if-there-s-irq_work.patch in order to revert the 1st patch)... I'm just having morning coffee and also reading through the linux-rt list now, which yes, seems to be tied to the same problem / likely to my issue. ~ I'm going to apply their fix and see if it boots successfully. Then, I can hit the list, later today - if the problem still exists.

jhernberg commented on 2014-02-01 12:28 (UTC)

@Ninez: Urgh, you are the first to report any real problems problems with this kernel image, it's working perfectly on my system, except for the occasional warning in the kernel buffer. For anyone else needing RT and having problems I'd recommend to permanently/temporarily trying the linux-rt-lts kernel. Reverting the old timers-do-not-raise-softirq-unconditionally.patch was what stopped the boot lockups of the last rt patch. I know that they have found another path to trigger the same bug now, and I think there is a proposed fix for that since yesterday on the mailing list. Don't know if this is the problem you experience but it seems likely. AFAIK the problem is also hardware dependent, and I don't recall seeing anyone else reporting a similar problem to yours, so I suspect it might really be a good idea to report your problems to the mailing list...

jrdnjhntn commented on 2014-02-01 11:59 (UTC)

@Jhernberg: linux-rt-3.12.8_rt11 fails to boot on my AMD Phenom II 965 x4 machine. Originally, my kernel wasn't booting (of the same version), so i ended up compiling yours/in AUR, which (obviously) failed in the same way, as it seems to be -rt patches that are causing the failure. So i went through and reverted these two patches (from the split-queue); 'timer-Raise-softirq-if-there-s-irq_work.patch' 'timers-do-not-raise-softirq-unconditionally.patch which then allowed my machine to boot - but wasn't stable (minute 1/2 to login after entering password / painfully slow). I see the linux-rt list has been busy over the last 24hrs or so [it looked possibly related, maybe...] ~ I still need to read through all of that + probably hit the list to report, assuming they are unaware of those fixes possibly breaking some machines... I thought I would mention it (to you) anyway. [ for now, I am sticking with -rt7, as it's been stable. ]

unknown78 commented on 2014-01-20 22:24 (UTC)

Ninez is right even i didn't do that inside of the user directory i used /etc/pulse/daemon.conf :) systemwide since i'm the only user

jrdnjhntn commented on 2014-01-19 15:26 (UTC)

@jhernberg - the solution that unknown78 is referring to is changing the rlimit-rttime setting in /etc/pulse/daemon.conf (or ~/.pulse/daemon.conf' for a particular user). I just checked my config; rlimit-rttime = -1 (; rlimit-rttime = 1000000 is the default.). eikakot should try changing that line (and that may be what i was thinking of when i made the 'exit-idle-time= -1' suggestion, as i said; it's been a long time since i have had to configure PA). Anyway,I just set mine back to the default settings and PA died after a while. rlimit-rttime is the culprit and as indicated in the LP bug report/link/comments; it's not that PA is crashing, it's getting SIGXCPU because of the rlimit-rttime. switched it back to -1 value and restarted PA - now PA is running as it should again, no SIGXCPU.

jhernberg commented on 2014-01-19 11:54 (UTC)

@unknown78: I tried to read that thread and am really not sure what the fix was? Could you please explain how you fixed it on your system?

unknown78 commented on 2014-01-18 20:48 (UTC) << towards the issue with pulseaudio (solved it for me on linux-l-pa)

jhernberg commented on 2014-01-12 13:32 (UTC)

@eikarot: Hmm, personally I don't use pulseaudio, so I don't really know how to help you with this... Have you found out anything more about the problem?

jhernberg commented on 2014-01-12 13:28 (UTC)

@ilkytest: Yeah, there was a patch that made the kernel hang very early on most boots of this i7-2600k. I have reverted that patch and the kernel seems to be fine now.

eikakot commented on 2014-01-04 22:23 (UTC)

'exit-idle-time= -1' did not help, pulseaudio stopped anyway. Not sure if that is related, but the last message from dmesg was: CE: hpet increased min_delta_ns to 20115 nsec

jrdnjhntn commented on 2014-01-04 20:26 (UTC)

@eikakot - 'exit-idle-time= -1' tells the daemon to disable exit-idle-time feature - which as the name (of the feature) implies; exits PA daemon after X amount of idle-time (after client exits). I seem to remember being 'bitten' by a similar (if not the same) problem you are having. you can have a read through here to understand PA's commandline options; (you can also read other doc sections from there.) I find it odd that you don't find this on Arch's default kernel. My memory also isn't the best, as it's been a while since PA gave me any issues, so i am not sure if i can of much assistance - beyond suggesting what i already have. (ie: exit-idle-time= -1, try enabling realtime scheduling/priorities and RTM/go through your configs). cheerz (ps: forum post might be better in this case too.)

eikakot commented on 2014-01-04 20:03 (UTC)

Well, I have recently installed arch on new ssd so pulseaudio config is the default one. I tried to add log-level = debug, but even if it gave me more information, there was nothing useful and no trace of a crash. Pulseaudio stops quite a lot when I'm listening to music so I know when the process stops, but I don't know why. Anyway, this does not happen on the stock arch kernel. Previously I didn't have any problems with that on arch, and the only difference now is that I switch to KDE. Maybe that has something to do? What does exit-idle-time do?

jrdnjhntn commented on 2014-01-04 13:50 (UTC)

@eikakot - I'm a user of PA on -rt. Question: does PA actually crash? (like a segfault or something) ... also, have you adjusted PA's settings at all? ( ie: in /etc/pulse/daemon.conf && /etc/pulse/client.conf ). adjusting the line 40 (in daemon.conf): exit-idle-time = -1 (changed to -1) stops PA from existing for me. let us know if that helps, k? You should have a look through your pulse configs, regardless, as you may find giving PA realtime-scheduling/priority could be useful. (for example, if you experience choppy sound at all, adjusting those settings would likely help). Anyway, it probably boils down to configuration - as PA works fine on -rt ...

eikakot commented on 2014-01-04 09:03 (UTC)

pulseaudio stops running occasionally with this kernel for some reason

jhernberg commented on 2013-12-29 11:53 (UTC)

@ilkytest: Install linux-rt or linux-rt-lts from the archaudio-production repo. Otherwise you can also to change a line in the PKGBUILD like this: "${_basekernel}/older/patch-${_pkgver}-${_rtpatchver}.patch.xz" Note the added "older". This happens because everytime a new patch comes out, the old one gets moved into the older subdirectory :( Will update the package builds when I get back from vacation and have the hardware to build and test them.

ilkyest commented on 2013-12-28 22:36 (UTC)

no boot... maybe incompatible patches... I'll wait new pkgbuild

ilkyest commented on 2013-12-28 17:29 (UTC)

I could try compiling changing md5sums like here but, I'm applying this patch now... I'm compiling it, and after I post here my results

ilkyest commented on 2013-12-28 17:18 (UTC)

The requested URL /pub/linux/kernel/projects/rt/3.12/patch-3.12.5-rt7.patch.xz was not found on this server.

jrdnjhntn commented on 2013-12-18 18:47 (UTC)

@jh - thanks for the clarification. (i thought your blue dots was your 650ti). I'm not a KDE user, but do use XMBC - my gt440 hasn't exhibited anything like you are reporting. (maybe i'll install KDE and see what happens... your mention of blue dots/areas DOES remind me of screencasting, if in Gnome-Shell/nvidia - i used to see that kind of thing / something similar - maybe not dots, but for sure blue-areas of corruption (just on plain nvidia, no -rt, no other patches.. But i don't use GS, haven't even looked at it since gnome 3.4). anyway, I've found someone with some expertise/experience with nvidia, who is going to help me go through some of this stuff. (he answered off-list or linux-rt-user list, said next week he should have some time to take a look/help me out... so at least that is good news).

jhernberg commented on 2013-12-18 13:00 (UTC)

@Ninez, i have 2 nvidia cards. The one I like to use in that machine is a GTX650Ti, with that card installed then machine hangs with linux-rt and nvidia-rt no matter how I patch the nvidia driver (tried all your patches). Thus I mostly don't bother with -rt on that machine as it's the media PC for watching TV/video and playing games. I also have an older 8600gts, with that card linux-rt and a plain nvidia-rt with no patches works absolutely fine. Just high scheduling latency at times. I tried that card with the both your patches and it seems like the nvidia-rt_no_wbinvd.patch creates some slight screen corruption, that is to say on the kde splashscreen and watching a video in xbmc, there are some blue dots (areas) that shouldn't be there. I'm hoping that phoronix is correct in reporting SteamOS using a -rt patched kernel, as that hopefully means that someday I can use -rt on that machine too.

jhernberg commented on 2013-12-18 12:51 (UTC)

@codekun: Next time you can/could. Think this time I was a little too fast, built a new kernel straight away when i found the rebase on Been taken care of now though.

jrdnjhntn commented on 2013-12-17 21:33 (UTC)

@Jhernberg: Sorry for the late reply (on testing out the patched driver). That's too bad about the Nv650Ti. - i hate when i buy H/W that doesn't seem to work well... When you say 'old nvidia' what do you mean? (like older driver/rt-compat patch?)... ..and when you say 'my patch' - you mean nvidia-rt_no_wbinvd.patch, right? <or did you try out the nvidia-rt_mutexes.patch for 331.20 too?). I don't know if it will help (the old nvidia-rt used mutexes, no?). regardless, it does sound like something quite odd is happening with that particular setup... PS: While i haven't had any feedback from nv, but I have talked to a few people who have been trying out no_wbinvd.patch - Everyone that i have talked to has been blown away by the differences in Cyclictest and not had any issues with it, afaik. I haven't run into problems using that patch either, uptime well over a week (2 weeks maybe?), on my one machine. <while this one I rebooted lastnight, after days and days of uptime.

coderkun commented on 2013-12-17 19:51 (UTC)

@jhernberg: patch “patch-3.12.5-rt5.patch.xz” does not exist anymore because of patch “patch-3.12.5-rt7.patch.xz”. Should I mark as out-of-date?

jhernberg commented on 2013-12-17 12:38 (UTC)

Both linux-rt and linux-rt-lts are available in binary format from the archaudio-production repo. If you trust us and want to just install either linux-rt or linux-rt-lts with pacman, just add the following to your pacman.conf: [archaudio-production] SigLevel = Never Server =$repo/$arch

jhernberg commented on 2013-12-17 12:27 (UTC)

I've taken over maintenance of linux-rt-lts too. Both kernels are similarly configured to the -ARCH kernel, the -rt-lts a little more conservative. linux-rt-lts is based on the 3.10 kernel which has long time support. I recommend people to use the -rt-lts kernel for production use and -rt for testing bleeding edge., in fact up until now I've always tested -rt on my own systems and held it back in case of problems. Now I intend to push -rt quickly as a testing branch and to regard -rt-lts as stable and the production branch.

jhernberg commented on 2013-12-17 12:06 (UTC)

@Ninez: I tried your patched driver and it still hangs with my 650Ti, with the old nvidia it works just as before. Possibly with lower latency, but I think there is something wrong, and many times I find the screen full of blue dots. Haven't had any time to make comprehensive tests though...

jhernberg commented on 2013-12-17 12:04 (UTC)

@david.runge: I'm sorry, I really have no idea how to help you with nvidia on -rt. I think the only one who could possibly help you is nvidia themselves... Maybe there is some light in the end of the tunnel, as I understand it SteamOS uses a PREEMPT_RT_FULL kernel, so I hope that we can reap the benefits too :)

jrdnjhntn commented on 2013-12-06 22:36 (UTC)

@David.runge - Wrong. You are experiencing entirely different issues (as i've pointed out to you in linux-l-pa comments). Switching to my packages will NOT solve your issues... If you were experiencing the 'same issues', you would see something like this; ... ie: "[37575.984113] BUG: scheduling while atomic: irq/42-nvidia/18410/0x00000002" ... But your problem(s), include; - [Firmware Bug]: ACPI(IGPU) defines _DOD but not _DOS - [ 5200.704206] BUG: unable to handle kernel NULL pointer dereference at 00000000000002c7 - [ 5200.704376] BUG: unable to handle kernel paging request at ffffffffffffffd8 - [ 1.164313] WARNING: CPU: 1 PID: 69 at kernel/time/tick-sched.c:191 can_stop_full_tick+0x175/0x280() [ 1.164314] NO_HZ FULL will not work with unstable sched clock <...and more. just search BUG: in your pastebin link> afaict, nvidia ISN't your problem. ACPI and the firmware for your IGPU seem to be the biggest issues and (as i said on linux-l-pa - you need to disable NO_HZ_FULL via nohz=off to grub commandline). Also, Your system appears to be a 'bumblebee' system, which could be introducing other potential issues. (but i have no experience with bumblebee, so i can't help you with that)

dvzrv commented on 2013-12-06 12:03 (UTC)

@Ninez & @jhernberg: Experiencing the same issues: At that point I wasn't using the rtirq script yet, but was trying to switch between the powermizer settings in nvidia driver settings (Auto to Maximum Performance). Apparently the driver didn't like that too much. @Ninez: guess I'll test your patched version now! :)

jrdnjhntn commented on 2013-12-05 18:36 (UTC)

I started a (fairly detailed) thread at nvidia; ... It may be like tossing a coin in a wishing well, but that's okay. - maybe it will lead to change :)

jrdnjhntn commented on 2013-12-05 16:47 (UTC)

@Jh thanks :) I'm not positive but i dont think wbinvd is all that critical (I'll hit the nv-dev forums on this though). - I've abused/tortured the hell out of nvidia for 2 days, no problems whatsoever.. well actually, the semaphore (vanilla) nvidia-rt throws some scheduling errors (nothing fatal), but the nvidia-rt_mutexes.patch(ed) version of nvidia-l-pa/-rt has ZERO warnings/errors (although obviously, it requires more care to not get throttled/choked.). anyway, once you free up some time - please let me know how it turns out for you / on nvidia. thx.

jhernberg commented on 2013-12-05 14:43 (UTC)

@Ninez: Congrats! I'll try it some day when I've sorted out this pstate mess on 3.12 :( Mind you wbinvd might be used on purpose, but using it would certainly explain a stall in kernel scheduling. The i915 driver was also problematic when they used it for a while in 3.10.

jrdnjhntn commented on 2013-12-04 03:06 (UTC)

@JH OT(sort of): (today) I squashed that long-standing nvidia latency spiking problem. You can find the patch (nvidia-rt-no-wbinvd.patch) here to test; ... I've written a short explanation in the comments, there. You'll need to apply both of the patches to nvidia, as X fails -> if you don't apply nvidia-325xx-rt.patch with nvidia-rt-no-wbinvd.patch. ~ The cyclictest numbers are *impressive*, no latency spikes and reduced latency. => launching 15+ tabs of video in Firefox (as quickly as i could) resulted in a latency spike of MAX: < 60 - and that was only 2 cores. My average MAX: is around 20-30 now :)

jrdnjhntn commented on 2013-12-03 23:06 (UTC)

@Jh 'whatever floats your boat' ;) I was mostly just pointing out that the low rtprios of ksoftirq might be your issue (with softirq_pending). As for the rcu s stuff, ya, check into it at your own leisure :)

jhernberg commented on 2013-12-03 21:43 (UTC)

@Ninez: I'll have to hold off on this, as it appears that on this kernel the cpu is running at full turbo even with the ondemand governor loaded. I've also taken on maintaining the linux-rt-lts kernel so a lot to do at the moment...:) Regarding the rcu priority boost, I don't know if it's beneficial to set it to a low priority. AFAI understand it would be specific to how you run your system.

jrdnjhntn commented on 2013-12-02 19:03 (UTC)

@jh I'm not going to claim to be an expert on the softirqd rtprios, but after some experimentation, I have mine set to 40 (while the lowest actual h/w IRQ+kthreads are rtprio 51. (rtirq sets the rest incrementally like usb/firewire/nvidia/etc). about rcu boost, i doubt you will notice anything with rtprio 1 (or even generally). I think the problem is to be seen if a non-boosted rcu gets choked out by higher rtprio threads (like in CPU-bound app situation with extreme load, then you want rcu very high prio like FF 98/99). But generally, i would tend to think giving it lower rtprio should be safe for most uses, no?

jhernberg commented on 2013-12-02 18:06 (UTC)

@Ninez: I've seen a couple of those NOHZ, msgs. 40/80 and some other one that i can't remember. I've also gotten stuff like this: [ 7189.221232] WARNING: CPU: 2 PID: 44 at kernel/time/tick-sched.c:161 can_stop_full_tick+0x26b/0x280() But that is a different bug, and doesn't seem to have an impact on scheduling. To what priority would you recommend boosting the ksoftirqd threads? Regarding RCU boost, I've left that off as I don't know what priority users are running their real time threads at, but possibly I should try setting it to 1 to see what the effects are. Too bad that it takes so much time to test stuff like this...:(

jrdnjhntn commented on 2013-12-02 17:17 (UTC)

@Jh out of curiosity, what is the occasional warning that you are seeing? ... is it "NOHZ: local_softirq_pending 40" messages, usually a few in a row? You might want to do a sanity-check on kernel threads <like /usr/bin/rtirq status>. * ksoftirqd/X <one per core> by default has rtprio=1 FF(FIFO), which after some checking; Steven Rostedt seems to suggest that this is intentionally a poor default > I raise ksoftirq/rtprio && boost rcu -> I get no more NO_HZ: warnings and less flux/jitter in cyclictest (5 dys uptime since manually making adjustments + heavy workloads/tests/bench'd)... If you are seeing softirq_pending warnings, you should experiment with raising ksoftirqs' kthreads, as that seemed to make sure (on my system) that they were scheduled in a timely fashion. (maybe i'm wrong and you are seeing something different, this is just a hunch). cheerz

jhernberg commented on 2013-11-30 15:17 (UTC)

After testing extensively on 3 systems, I've changed to configuration to NO_HZ_FULL(_ALL). So far it hasn't shown any problems except an occasional warning in the kernel buffer. Scheduling latency times so far is just great. Please let me know of any problems!

jhernberg commented on 2013-11-26 08:44 (UTC)

OK, bumped to 3.12.1-rt4 configured with NO_HZ. If you need the lowest kernel scheduling latencies, I recommend booting with nohz=off as nohz seems to slightly increase latencies. Unlikely to be an issue for low latency audio, but if need the lowest latencies possible...

jhernberg commented on 2013-11-25 12:07 (UTC)

I think I'm gonna let the 3.12-rt kernel go out with NO_HZ_IDLE configured, and test the rest of the NO_HZ options for a while. Unfortunately I don't think I have time today to create the config files and build binaries for both platforms, but I will do my best to get it done promptly.

jrdnjhntn commented on 2013-11-25 00:56 (UTC)

NO_HZ_FULL_SYSIDLE=y is fine too -> not that it would be enabled on a production system anyway, so i am fairly confident that the corner cases (like myself and a couple of people i know) where NO_HZ_FULL was seeming to be an issue, should be okay now. btw (@Jhernberg) you were right about it likely not being about nvidia, as there was someone without nvidia H/W that was experiencing lockups on -rt1 && -rt2 but NOT -rt4.

jrdnjhntn commented on 2013-11-24 23:53 (UTC)

@Det && @Jhernberg 3.12.1-rt4(and -l-pa) with CONFIG_NO_HZ_FULL_ALL=y seems to be okay on my machines and several other people that were having problems previously. I still need to test NO_HZ_FULL_SYSIDLE=y - but I've also got positive feedback today on that (from the same people who were having problems on -rt2). @Jhernberg, on nvidia: I don't experience the latencies with nvidia that you do in Cyclictest <ie: MAX: in the 1000s>. Typically, on all workloads, with 2 exceptions my MAX: on any given CPU core is around 70-80, under load. ~ the 2 exceptions to these are: A).launching a VM in VMware can cause latency spikes (MAX: 800-900 on 2-3 cores) ...or B). if i close a tab that is playing a youtube video, in might introduce MAX: 200-300, but usually it's 100-120 (on 1 or 2 cores). ~ My nvidia boxes' MOBOs are designed with Nvidia/SLI in mind, "Extreme Edition" type MOBOs. so maybe that has something to do with it.

Det commented on 2013-11-24 21:35 (UTC)

So how's 3.12.1-rt4?

jrdnjhntn commented on 2013-11-23 01:37 (UTC)

@jhernberg: Ya, you don't need to patch nvidia anymore - I also have tested that. (maybe with 1000+ hits in my nvidia-rt thread, they actually fixed an issue in their driver...lulz) NO_HZ_FULL locks my primary machine up in under five minutes on (vanilla)3.12.0-rt2 :( ..and with NO_HZ_FULL_IDLE - on one run, i did manage to spot dmesg backtrace for nvidia before locking up (about a minute later). The backtrace was just like happens on BOTH of my nvidia boxes with the 'old' CONFIG_NO_HZ_IDLE (which btw, they have different MOBOs/vendors, components, etc AND different nvidia cards - but both are AMD Phenom II CPUs<not the same model though>).. While nvidia may not be the entire cause, I am not going to rule it out as playing into the problem, since clearly my machines are telling me that nvidia has _something_ to do with it. (ie: it ain't complaining about a network card or something, only nvidia + no_hz_idle or no_hz_full_idle in two configs/systems). I've sent out a couple emails + configs to get some of my friends to have a look, test and report back on each case + give H/W info. I'm probably going to set aside some time on sunday to work on this more (i should have feedback from others by then). After that (and after building the 3.12.0-rt4) i may hit the RT-list.. OT, but Funny how they fixed a deadlock on -rt2, yet -rt2 is the first kernel that i am getting deadlocks

jhernberg commented on 2013-11-22 12:25 (UTC)

@Nines: To clarify my previous post, it runs fine on the 8600gts and hangs on the 650ti as always :(

jhernberg commented on 2013-11-22 12:23 (UTC)

@Ninez: Don't think it has to do with nvidia. Have 3.12.0-rt2 with full NO_HZ options enabled, nvidia 331.20 (without your patch) and it seems to run fine. 1.5 hours uptime playing video and no hang. As always cyclictest results in the 1000s of usecs instead of 30-40 like my i915, but that has been like that as long as I can remember... Might be a good idea if you report your problems to the linux-rt mailing list, as they are under the impression that the deadlock ought to be gone in -rt2.

jhernberg commented on 2013-11-22 10:06 (UTC)

@Ninez: Seems like no matter what I do, it just won't run -rt on the 650Ti (at least for me and on this machine). Tried the nohz=off boot flag, tried a 3.12.0-rt2 kernel configured with HZ_PERIODIC, tried nvidia 331.20 with and without your patch. Nothing seems to make it go. Think I'll try a 3.12.0-rt2 build with NO_HZ_FULL_ALL on the 8600gts to see if that works fine.

jrdnjhntn commented on 2013-11-22 02:43 (UTC)

@Jhernberg - I agree (as i was sort of implying) it very well could be related to nvidia. I was actually going to suggest you trying NO_HZ_PREIODIC on your (nvidia) system (that always freezes) to see if it made a difference. - it would be nice to know if your system still hangs. <then we KNOW it's nvidia related.> My buddy is on nvidia, but i'll have to ask other people on that (i think another user was on radeon, but i'm not positive. I just got in, so i'll have a look at NO_HZ_FULL before bed / let you know tomorrow (it's a bit late here). cheerz

jhernberg commented on 2013-11-21 23:20 (UTC)

@Ninez: Beh, maybe it's nvidia related then.. Just ran a 3.12.0-rt2 kernel with NO_HZ_FULL for 7 hours testing with excellent cyclictest results, but that is a i915 system. Max result was 33usecs.. I have a nvidia system that always hangs with -rt when using a 650ti, but works fine with a 8600gts... Hopefully NO_HZ_PERIODIC can solve it... Will test tomorrow. Are your friends with hanging systems also nvidia users?

jrdnjhntn commented on 2013-11-21 18:37 (UTC)

@Jhernberg - Yes, dead positive that NO_HZ_IDLE hoses my machines, with plain-jane vanilla 3.12.0-rt. <After all, the first thing i did after experiencing lockups on 3.12.0-rt2 was build a vanilla/rt kernel to test against. ie: i usually have matching -l-pa && -rt kernels installed, at any given time>. I'll have to double-check on NO_HZ_FULL, although i can tell you right off the top of my head both NO_HZ_IDLE && NO_HZ_FULL nvidia blob doesn't seem to like - as i get 3-5 backtraces regarding nvidia while using those settings. On the other hand CONFIG_HZ_PERIODIC=y gives me ZERO issues with nvidia. Regardless, I will double-check NO_HZ_FULL to be 100% postive on lockups and let you know - I'm @ work right now, but i should get a chance later tonight to check.

jhernberg commented on 2013-11-21 08:03 (UTC)

@Ninez: Are you sure that your NO_HZ_IDLE problems stem from the rt patch and not one of the many other patches you apply? That is to say does a kernel with just the -rt patch applied and NO_HZ_IDLE or NO_HZ_FULL also hang?

jhernberg commented on 2013-11-21 07:40 (UTC)

@Ninez: That's an unfortunate report...:) I have been running 3.12.0-rt2 configured with NO_HZ_FULL/NO_HZ_FULL_ALL/NO_HZ_FULL_SYSIDLE for about 17 hours now, with just some initial garbage in the kernel ring buffer, otherwise excellent cyclictest results. Now I don't really know what to do.... I can however verify that NO_HZ_FULL/NO_HZ_FULL_ALL/NO_HZ_FULL_SYSIDLE hung 3.12.0-rt1 quickly here. I will build another kernel with just NO_HZ_FULL as that most likely is the best option to use for a production kernel (if it works :) and see how that holds up on this system. Maybe I'm gonna have to post a build to my dropbox, so that I can get some feedback about how well it holds up on other systems.

jrdnjhntn commented on 2013-11-21 00:43 (UTC)

@Jhernberg - Yeah, I knew NO_HZ_IDLE got 'pulled in' with those options - I've opted to NOT use NO_HZ_FULL - being as it didn't work at all on -rt like a week or so ago. ;) ...Instead, i am using CONFIG_HZ_PERIODIC which is reliable, tested, proven.

jhernberg commented on 2013-11-21 00:07 (UTC)

To clarify, as I understand it in 3.10, NO_HZ was replaced by NO_HZ_PERIODIC, which is the old timer tick behaviour, by NO_HZ_IDLE which is the old NO_HZ behaviour and by NO_HZ_FULL which adds the capability of not sending scheduling interrupts to cpus only running one task. The latter must be enabled by the user using the "nohz_full=..." kernel boot option or by configuring NO_HZ_FULL_ALL.

jhernberg commented on 2013-11-20 23:33 (UTC)

@Ninez: Actually I was spreading untruth just now. I configured my kernels with NO_HZ_FULL, NO_HZ_FULL_ALL and NO_HZ_FULL_SYSIDLE. NO_HZ_FULL also enables the NO_HZ_IDLE functionality. But I think I will build a new kernel with just NO_HZ_FULL for now, to see how that goes.

jrdnjhntn commented on 2013-11-20 21:14 (UTC)

I kinda figured as much (that CONFIG_NO_HZ_IDLE was the cause), that's why after reading your comment to martadinata666, i thought i should make the suggestion to disable CONFIG_NO_HZ_IDLE, since i had tackled with that issue on -rt2 just a couple of days ago. <ie: save you the hassle/time, if you hadn't gotten around to investigating yet>. I don't think there is an overly huge rush for 3.12-rt, as you say; 3.10-rt works quite well... I will say though, 3.12.0-rtX isn't bad for an early release, aside form the initial no_hz_idle issue - no big deal though :)

jhernberg commented on 2013-11-20 19:37 (UTC)

For me 3.12.0-rt1 hung very quickly with CONFIG_NO_HZ_IDLE, but I haven't had all that much time to build kernels and check different configs. 3.10-rt seems to work quite well though, but am working on getting this going. Still very early days for 3.12-rt though...

jrdnjhntn commented on 2013-11-20 19:29 (UTC)

Ah, good to hear. I just thought i would mention it, as; 3.12.0-rt + CONFIG_NO_HZ_IDLE has been problematic for several people that i know, including myself; 3.12.0-rt1 seemed fine with CONFIG_NO_HZ_IDLE. however, 3.12.0-rt2 with CONFIG_NO_HZ_IDLE is VERY unstable for me (yes, lockups)... may be to do with COFNIG_NO_HZ_FULL changes on -rt2, i'm not sure / haven't had time to investigate fully.

jhernberg commented on 2013-11-20 18:57 (UTC)

@Ninez: I built 3.12.0-rt2 today without CONFIG_NO_HZ_IDLE, and so far mostly good. Still up and running, and nice cyclictest values. Am building one with CONFIG_NO_HZ_IDLE too, to see if that does better than -rt1.

jrdnjhntn commented on 2013-11-20 18:21 (UTC)

@Jhernberg - try disabling CONFIG_NO_HZ_IDLE feature and see if you still get lockups.

jhernberg commented on 2013-11-14 16:05 (UTC)

@martadinata666: Yeah, I'm not quite sure myself... Normally I follow the distro kernel, in order for the config and patches applied to be as close as possible to the distro default. Also I've booted a couple of attempts at building 3.12.0-rt1 and all have locked the machine hard within minutes. Ime it's normally better to wait until -rt10 or so for a specific kernel release as it's normally at this point that it starts to stabilize... That said I try to keep a production ready kernel in archaudio-production and the bleeding edge here in AUR. Will update when I have a kernel that builds and doesn't hang/crash for me. The other question that arises now, is linux-rt-lts. But first let's see what -rt upstream thinks about lts.

martadinata666 commented on 2013-11-13 02:40 (UTC)

3.12 released :) i don't know if you follow the mainline or not, so i dont mark out-of-date

forkenbrock commented on 2013-09-05 04:06 (UTC)

Turns out my mistake was not realizing I needed to also install the headers and docs files created in the makepkg. Recovering the other OS was problemating, but after starting over I'm able to get the kernel running now. Thanks for your help.

jhernberg commented on 2013-09-03 10:27 (UTC)

@forkenbrock: FWIW, I've installed the linux-rt package on this laptop, and my system boots just fine, so most likely this package has nothing to do with your boot problem, and you need to fix your boot manager to find the vanilla kernel so that you can bring up your system again.

jhernberg commented on 2013-09-02 09:38 (UTC)

I have problems to visualize how installing this package could possibly break your normal archlinux boot. IMO what you need to do, depends on what boot manager you use. Fixing the boot manager to point at your vanilla archlinux kernel most likely would make your system bootable again. Basically this package installs vmlinuz-linux-rt and initramfs-linux-rt.img into /boot, it also installs modules into /usr/lib/modules/3.10.10-rt7-1-rt and creates /usr/lib/modules/extramodules-3.10-rt if it doesn't already exist. None of it anything that could possibly break the system (as far as I can see). Being on vacation I only built the 3.10.10-rt7 kernel before uploading it to AUR, I didn't install it on my laptop to test, will do that this afternoon though.

forkenbrock commented on 2013-09-02 07:43 (UTC)

I got into a bit of trouble here and was wondering if someone can help. First I made the RT package and noticed no errors, except failed to find locale. However, when I installed the package and rebooted my machine was no longer bootable. Both the regular and fallback boot entries in GRUB show several "failed to mount" messages and there's a blinking prompt at the bottom that doesn't do anything when I type. I have a 2nd failed RT install entry in GRUB, from an attempt at the traditional config/install method, that's able to boot into a rootfs prompt. Looking for advice for what I can do, if anything, to get it back or do I need to start over. Also, is there something I may have done or not done to cause this? I simply downloaded the RT package and used these commands. makepkg -s pacman -U linux-3.10.10-rt7-1-i686_64.pkg.tar.xz Thanks

jhernberg commented on 2013-08-31 22:41 (UTC)

Ok uploaded, but not tested :)

jhernberg commented on 2013-08-31 22:28 (UTC)

Ah, and I forgot to add: run "makepkg -g >> PKGBUILD" to update the checksums if you are getting the newer version.

jhernberg commented on 2013-08-31 22:26 (UTC)

Yeah, the problem that breaks the script is that the -rt patch is moved to another url when a new one comes out. Best course of action would be to either wait or just to update the _releasever and _rtpatchver variables. Will most likely work fine with no config file updates. The third solution would be to change the line reading: "${_basekernel}/patch-${_pkgver}-${_rtpatchver}.patch.xz" for "${_basekernel}/older/patch-${_pkgver}-${_rtpatchver}.patch.xz" Am building the new kernel now and will upload a fix when it's done.

Morgan_Cox commented on 2013-08-31 21:14 (UTC)

Currebt version is : linux-rt-3.10.10_rt7 If you want it now before the package is updated, You can just make the following changes to the start of the PGKBUILD ----------------------------------------------------------------------- # Maintainer: Joakim Hernberg <> # Contributor: Ray Rashif <> # Contributor: timbosa <> # Contributor: Tobias Powalowski <> # Contributor: Thomas Baechler <> pkgbase=linux-rt pkgname=('linux-rt' 'linux-rt-headers' 'linux-rt-docs') # Build realtime patched -rt kernel #pkgname=linux-custom # Build kernel with a different name _kernelname=${pkgname#linux} _basekernel=3.10 _releasever=10 _rtpatchver=rt7 pkgrel=1 _pkgver=${_basekernel}.${_releasever} pkgver=${_basekernel}.${_releasever}_${_rtpatchver} arch=('i686' 'x86_64') url="" license=('GPL2') makedepends=('xmlto' 'docbook-xsl' 'kmod' 'inetutils' 'bc' 'ncurses') options=('!strip') source=("${_basekernel}.tar.xz" "${_pkgver}.xz" "${_basekernel}/patch-${_pkgver}-${_rtpatchver}.patch.xz" # the main kernel config files 'config' 'config.x86_64' # standard config files for mkinitcpio ramdisk "${pkgname}.preset" 'change-default-console-loglevel.patch') md5sums=('4f25cd5bec5f8d5a7d935b3f2ccb8481' 'd010ef17d3e577fd1bdcb6887f2b9836' 'b634614a96f47a564bc32bc87afe587f' '9b9b8dea000bce8f3e8259752e299370' 'd8597d281ae4b9776fb730acd86f144f' 'eb14dcfd80c00852ef81ded6e826826a' 'f3def2cefdcbb954c21d8505d23cc83c')

forkenbrock commented on 2013-08-31 20:40 (UTC)

I get the 404 error as well. As Morgan said, 3.10.9 is no longer posted, but maybe your script is set to automatically select the most current version?

Morgan_Cox commented on 2013-08-31 10:10 (UTC)

Hi Getting 404 ----------- curl: (22) The requested URL returned error: 404 Not Found ==> ERROR: Failure while downloading patch-3.10.9-rt5.patch.xz Aborting... ----------- Looks like it been bumped to patches-3.10.10-rt7.tar.xz

jhernberg commented on 2013-08-30 10:03 (UTC)

@svictor: That's a bit strange, if cyclictest shows no anomalies, then afaik the kernel and hardware in general is working well. Would suggest that the problem lies in the audio hardware or setup, but on the other hand you say an older kernel works fine... I'll see what I can come up with once I get home and can put 3.10-rt to the test myself. Just as a wild goose chase, anything weird in dmesg that aligns with the xruns? What hardware do you have (chipset, cpu, gpu, audio)?

svictor commented on 2013-08-28 09:40 (UTC)

I tried the do_wbinvd=no option but it didn't make any difference. Cyclictest gives acceptable max values (around 70-80). I ran it also when using Ardour. I expected the max value to jump when the bursts of xruns occured in Ardour. But they didn't: cyclictest continued unaffected while Ardour and jack lagged behind. I don't think it's a problem with my audiosetup because I don't experience this with other kernels. Thanks for your help and for the useful information! I'll stick to a lower release for now and retry 3.10 later maybe.

jhernberg commented on 2013-08-26 13:54 (UTC)

I forgot, to get a good result out of cyclictest it would be useful to put some load on the system. If it's a modern cpu this is kind of hard, but compiling a kernel on all cores or something like that would do it.

jhernberg commented on 2013-08-26 13:51 (UTC)

@svictor: Yes, add "options i915 do_wbinvd=no" to some .conf file in /etc/modprobe (like modprobe.conf or 20-i915.conf). Unfortunately I think the normal driver refuses to load if you boot with this option with the vanilla kernel :( taskset could indeed be used to set the affinity of a process (to make sure that it only runs on a single cpu), something like "taskset -p 1 <PID>" would pin the process PID to cpu 0. Mind you I've stopped doing this and haven't noticed anything breaking. To verify kernel scheduling you can install a toolset called rt-tests and run the command "cyclictest -m -Sp98 -i100 -d0", this will try to run a thread on each cpu at priority 98, sleeping for 100usec and then schedule it for execution. The results you are interested in are the max values, which indicate how long it takes to for a scheduled thread to be executed (in usecs). Hopefully you'll see values less than 100usecs. If you see values orders of magnitude higher, then there is something wrong and the kernel simply can't execute your thread fast enough, which will cause xruns (depending on the latency you are trying to achieve).

svictor commented on 2013-08-26 13:09 (UTC)

Thanks for the detailed explanation! I do have an Intel card. If I understand correctly, on recent kernels I should load i915 with an option to avoid latency spikes. Is this do_wbinvd=no, which you mention in another comment? There you wrote to also "pin all processes using the graphics driver on a single cpu. Basically X and any process that opens /dev/dri/cardX, try "fuser -v /dev/dri/cardX" to see what processes this might be." I understand the part with fuser. But I'm not sure about how to pin processes to a CPU. I searched and found something about using taskset from schedutils: taskset -c 1 -p <PID>. Is that it? If so, I'd give 3.10.9 another try. Thanks again for your help!

jhernberg commented on 2013-08-26 11:59 (UTC)

@svictor: hmm, i gave that comment and left linux-rt at 3.8.11-rt8 due to some problems with intel graphics. supposedly a hardware bug was discovered and the intel driver needs to flush the cpu cache causing spikes in kernel scheduling latency. This is done in later kernel, and needs to be worked around with a i915 module option. I've never noticed a problem with graphics, but do notice the latency issue in later kernels when not employing the module option. That said, the realtime patch is in constant development and sometimes quite buggy, so user beware. the latest is not always the best... On the other hand i have two systems that seem to behave ok with 3.10-rt, one has an uptime of 11 days and runs 3.10.4-rt1 (not updated since i'm on vacation). Been considering to upload 3.10.9-rt5 to archaudio-production but will hold off for a while longer. The usual folklore is that the patch is stable when it reaches -rt10 or so :) I don't know a way to keep several versions of this package installed, unless you edit it and rename the kernel, but that is bound to be a bit difficult due to all the trickery employed to build the archlinux kernel (which this package mirrors). Probably the best course of action would be to take the kernel config file, and then manually build and install the kernel. like that you could easily keep several -rt patched kernels and their modules installed simultaneously. If you have problem with 3.10-rt, maybe edit the the 3.8-rt buildscript to build 3.8.13-rt15. Some people say 3.8 is a horrid kernel, but if it works for you :)

jhernberg commented on 2013-08-26 11:36 (UTC)

@forkenbrock: install the package devtools, and build the kernel package with either # extra-x86_64-build or extra-i686-build. This will build the kernel in a chroot with all the needed packages installed, and no strange interactions with your normal system. This is really the best way to build any package you need, as it will assure that the package is built the way the author meant for it to be.

svictor commented on 2013-08-26 11:03 (UTC)

On my machine, 3.10.9_rt5 gives many xruns and crashes Ardour often. So I downgraded to 3.8.11-rt8 following a comment here below by jhernberg (and thanks for the link to the older pkgbuilds: very helpful!). I'd like to know what I should alter in the pkgbuild in order to keep the rt-kernels installed previously. Current behavior on up/downgrade is to remove them. What should I do to keep the other versions available in grub? Another question: in your experience is 3.8.11-rt8 still the latest usable kernel for audio?

forkenbrock commented on 2013-08-25 18:25 (UTC)

I don't know if the package called "bc" should be a dependency, but I received a compile error until I installed it.

jhernberg commented on 2013-08-23 15:13 (UTC)

For 3.10.9-rt5 bcache is still disabled, and on i686 I had to disable the hwlatency module too.

ackalker commented on 2013-08-23 12:26 (UTC)

Because I don't see it mentioned (browser search through all comments), I'd like to add: If you know for sure you have enough RAM to build the kernel in /tmp but the build fails because the tmpfs is too small, you can adjust itson the fly (make it bigger, build the kernel, then restore it to its original size if you want): $ sudo mount -o remount,size=xxM tmpfs /tmp/ (replace xx with something reasonable) Source:

jhernberg commented on 2013-08-18 16:16 (UTC)

That sounds like the best solution for yaourt users with insufficient ram to build the kernel in a tmpfs. Thanks for helping me understand the issue!

capoeira commented on 2013-08-18 15:47 (UTC)

this time it got through with 20MB left on tmpfs... lol I will start to use --tmp option with yaourt for kernel builds

capoeira commented on 2013-08-18 15:43 (UTC)

actually, easiest solution for yaourt is to use --tmp option and let it build on harddisk. but I'm trying it again atm on tmpfs. 80% usage allready

jhernberg commented on 2013-08-18 15:25 (UTC)

Hmm, don't know much about yaourt. I'd still recommend you to use the scripts from devtools, but if you are dead set on using yaourt I'd do the following: 1. Follow: to configure yaourt to build packages on /var/tmp instead of /tmp, as that is on your / filesystem, and supposedly won't run out of space. The disadvantage being that all other builds will be slower seeing that tmpfs is much faster. 2. Let systemd mount /tmp on a tmpfs as that will speed up your computer in general. But imo this is basically a yaourt problem. It shouldn't default to build on /tmp anymore seeing that nowdays it's a tmpfs and will eat up your ram. Let each user decide for themselves if they want to change it to build on a tmpfs instead...!

capoeira commented on 2013-08-18 15:03 (UTC) was first compile since boot, and tmpfs (2GB) got full.....I'll try again and let you know if fstab was the problem.

jhernberg commented on 2013-08-18 14:51 (UTC)

@capoeira: How did you try to build this package to run out of space on /tmp? With makepkg, yaourt, something else? I really would like to understand what the problem is..

capoeira commented on 2013-08-18 14:44 (UTC)

thanks, I comented it out and will try again.

jhernberg commented on 2013-08-18 14:24 (UTC)

Well with systemd it's redundant, since it will mount /tmp on a tmpfs all by itself.. Actually you can remove most of everything in fstab, except for what mounts your /, /home, swap and whatever other partitions you explicitly want to mount. For instance this laptop only has the following: UUID=2c53c536-7bfb-4890-b389-ff03a95c4420 / ext4 rw,relatime 0 1 UUID=ee2fcc09-635b-4d5c-b530-908e9da038cc /home ext4 rw,relatime 0 2 UUID=4916023d-1272-401c-be72-b2d81d55cbf3 none swap defaults 0 0 But If you want to stop /tmp from being mounted as a tmpfs, then you also need to mask it out to stop systemd from doing it. Something that "systemctl mask tmp.mount" ought to take care of.

capoeira commented on 2013-08-18 14:01 (UTC)

o, i have the line in fstab: >tmpfs /tmp tmpfs nodev,nosuid 0 0 you say this should be removed with systemd?

jhernberg commented on 2013-08-18 13:52 (UTC)

How strange, this is the second time I hear that the build is too big for /tmp (tmpfs). I wasn't aware that building a kernel uses a lot of space in /tmp... What are you using to build the package? I'd hate for this to be a generic problem on computers with little ram, as archlinux mounts /tmp as a tmpfs by default. I can think of 2 solutions off the cuff. One is using the extra-x86_64-build and extra-i686-build scripts from devtools. They build in a chroot located in /var/lib/archbuild, and I don't think they would use a lot of space in /tmp (I might be wrong though)...? But I'd really recommend you to always use these scripts for all packages that you build locally, as they will make sure that the package you build is built as intended. The other solution is to to stop systemd from mounting /tmp as a tmpfs. "# systemctl mask tmp.mount" ought to take care of this. Check fstab too, in case you have some old entry mounting /tmp as a tmpfs. Can you please provide some more details on how you build this package since I'd really like to get to the bottom of this. Am gonna try to build a kernel later myself to check what happens, but I am on vacation and my dialup is throttled to 128kbs, so getting the kernel sources will take forever...

capoeira commented on 2013-08-18 11:37 (UTC)

this build is getting to big for my tmpfs.....any workaround?

boulogne75 commented on 2013-08-16 20:21 (UTC)

Sorry again and thanks.

jhernberg commented on 2013-08-16 20:17 (UTC)

@boulogne75: Don't worry about it, Was far less time consuming than updating the package :)

boulogne75 commented on 2013-08-16 18:53 (UTC)

I am sorry, I was going to vote for this package but I pressed "flag out of date" button. I don't know how to undo it.

jhernberg commented on 2013-08-13 13:07 (UTC)

@Ralf_Mardorf: That happens everytime that a new patch comes out. Btw, I seem to remember you having done a lot of midi jitter testing, how are these linux-rt kernels in that respect? At some moment I'd like to configure a kernel without CONFIG_HZ_1000 and with full tickless support, don't know what effect that would have on midi though (supposedly the only reason to use CONFIG_HZ_1000)

Ralf_Mardorf commented on 2013-08-12 18:08 (UTC)

The patch moved to .

jhernberg commented on 2013-08-10 17:42 (UTC)

I had to disable bcache support to build the 3.10.4-rt1 kernel. Appears to run fine on Intel gpu hardware, but I still have to use i915 module parameter do_wbinvd=no, to avoid huge kernel scheduling latency spikes. Not tested on any other gpu hardware.

jhernberg commented on 2013-06-29 17:31 (UTC)

Seems to work fine so far, so have uploaded -rt13

jhernberg commented on 2013-06-28 16:42 (UTC)

I'll hold off on -rt13 for now, as there has been some preliminary reports of trouble. Will boot it myself to see how it holds up. Regarding the high latencies that i mentioned before, it seems that they are specific to the intel i915 driver on smp systems. As a workaround use the i915 module parameter do_wbinvd=no, and then pin all processes using the graphics driver on a single cpu. Basically X and any process that opens /dev/dri/cardX, try "fuser -v /dev/dri/cardX" to see what processes this might be.

smoge commented on 2013-06-22 03:33 (UTC)


smoge commented on 2013-06-14 20:02 (UTC)


paum commented on 2013-06-14 08:02 (UTC)

thank you, I want to try 3.2 series, because my presonus VSL 1818 makes xruns on 3.6 and 3.8. best

jhernberg commented on 2013-06-14 07:35 (UTC)

OK, I've uploaded an archive again.

paum commented on 2013-06-13 09:06 (UTC)

@jhernberg please, could you post again the zip with tarballs. I promise I will not lose them again ;) Thank You.

jhernberg commented on 2013-06-12 11:33 (UTC)

To be more precise, I mean the mailing list.

jhernberg commented on 2013-06-12 11:30 (UTC)

For anyone experiencing problems with the -rt patched kernel, I'd like to reccomend posting the details on the linux-rt mailing list, as they are the only ones that can fix your issues... A FYI, I've just discovered that on my system the last 3.8-rt offering really low latency is 3.8.11-rt8, the later kernels cause much higher latency spikes (in ms range)..! Seems to be an error in the vanilla kernel and not in the -rt patch itself, but still haven't managed to figure out what it is that breaks it.

smoge commented on 2013-06-12 08:59 (UTC)


jhernberg commented on 2013-05-08 07:41 (UTC)

@bparker Afaik, /sbin is part of the user path by default, so something must have gone wrong on your system.

bparker commented on 2013-05-07 20:23 (UTC)

Just FYI I had to manually add /sbin to my user's PATH to get the package to build, as it was failing to find the depmod executable.

paum commented on 2013-04-26 11:06 (UTC)

Thank you. yes, i need PKGBUILDs. because with this new kernel I have broken suspend & xruns with Presonus 1818VSL. some kernel in 3.6.x series was the best for my setup... thanks again & all the best

jhernberg commented on 2013-04-26 08:31 (UTC)

@paum: if you mean tarballs for the kernels themselves, they are all on If you mean the old PKGBUILD scripts, these are the ones i still have: Note that since the rt patches change location when a new patch is released, you'd have to update the path in the buildscript.

paum commented on 2013-04-25 07:35 (UTC)

jhernberg, do you have older tarballs from kernels 3.6.x & 3.7.x ? Could you upload them somewhere? Thank you. anyway, thanks for packaging.

Det commented on 2013-03-25 13:30 (UTC)

Seems like for the devs too: Btw, the upstream URL redirects to https:// anyway, so you should change it that way by default.

jhernberg commented on 2013-03-25 10:37 (UTC)

3.8..4-rt1 fails to build for me, so we'll have to wait for a new one

jhernberg commented on 2013-03-23 13:21 (UTC)

I don't have much time this weekend, but am building a 3.8.40rt1 for myself, and hopefully I find enough time to test it, and get a new script up quickly. So we'll probably skip 3.6.11-rt31 completely. Didn't look, but most likely it just fixes the GPL export issue.

jhernberg commented on 2013-03-23 13:19 (UTC)

I know, but I normally do some testing when there is such a jump in versions as 3.6 to 3.8 before I unleash it on the unsuspecting public... There is no testing for aur, and of course it's up to each if they want to get packages from aur, but that still doesn't mean that i would happily break their systems... The reason that I broke nvidia is simply because I didn't test on a nvidia system before releasing the upgraded script.. There was a change in the -rt patch that exported a function call as GPL, which had the unforseen consequence of breaking the nvidia driver as it's not GPL. It wasn't done on purpose, but a side effect of the nvidia driver being proprietary. Wish I would have caught it before uploading 3.6.11_rt30-1 to aur breaking users systems.

Det commented on 2013-03-23 12:42 (UTC)

3.8.4-rt1 is actually already there: What's this GPL problem you're talking about?

jhernberg commented on 2013-03-23 11:10 (UTC)

Heh, waited so long for a new patch before I asked if I could patch the GPL problem, and then another patch comes out the day after. The problem is that the patch gets moved on when a new one comes out. I've uploaded a new PKGBUILD that looks in the right place, and will get 3.6.11-rt31 up as soon as I had time to test it briefly.

eikakot commented on 2013-03-23 08:41 (UTC)

curl: (22) The requested URL returned error: 404 Not Found ==> ERROR: Failure while downloading patch-3.6.11-rt30.patch.xz

jhernberg commented on 2013-03-22 14:31 (UTC)

I've gotten permission to patch the kernel source making nvidia work again. Please let me know if there are any problems with the new build and nvidia, since I can't test it right now myself.

dvzrv commented on 2013-02-26 15:45 (UTC)

@jhernberg: nope, not yet. Will do if this version fails, too.

jnbek commented on 2013-02-13 21:41 (UTC)

I wish that the 32 bit OSs would die in a fire already... </rant>

jhernberg commented on 2013-02-13 21:39 (UTC)

Heh, didn't take all that long after all...:) Enjoy..

jhernberg commented on 2013-02-13 10:08 (UTC)

Seems like a fix for i686 will take a while, so here is a script that builds without editing. It's the same as 3.6.11-rt25-1 (which has been out for quite a long time).

jhernberg commented on 2013-02-06 21:06 (UTC)

Update: 3.6.11-rt28 doesn't compile on i686 so am waiting for a version that fixes it. Anyone wanting this kernel either has to edit the script to update the path to the patch, or download the binary kernel packages from the [archaudio-production] repo at Server =$repo/$arch

jhernberg commented on 2013-02-06 21:02 (UTC)

@david.runge did you get your problem fixed? If not, maybe asking on the linux-rt mailinglist would be a good idea

dvzrv commented on 2013-01-08 16:18 (UTC)

Okay, "working" with acpi=off now... and breakage ( :/ Anyone possible know what this could be? Seems related to the irq_cfg_pointer patch... but I don't know for sure... it messes with forcedeth. Pretty unusable without acpi. I'm not quite sure what to do... With acpi on it will just die in a freeze lockup (after loading some modules and services) with no logs at all. So I'm not very sure what happens there :/

Det commented on 2012-12-24 03:09 (UTC)


jhernberg commented on 2012-12-17 12:22 (UTC)

@martadinata666, I am not quite sure what you mean. The config file for i686 is called config, and for x86_64 it's called config.x86_64. The right one gets copied to .config in the script, see: lines 85-89.

martadinata666 commented on 2012-12-17 11:01 (UTC)

i can't find the RT patch config inside make menuconfig ?

fivedigits commented on 2012-12-12 10:28 (UTC)

link to patch-3.6.9-rt21.patch.xz is broken, patch now resides in http:// please update

newkular commented on 2012-12-03 19:34 (UTC)

patch-3.6.8.xz and patch-3.6.8-rt19.patch.xz are available, so this is technically out of date at the moment. Please update PKGBUILD: _releasever=7 ==> _releasever=8 _rtpatchver=rt18 ==> _rtpatchver=rt19 134936c362d8812b5cafcf3c67afdce0 ==> f248294551c34753c5c019c8d513280c 01f97c0630de43763699d580f48e1c74 ==> c075e8565172df1d77e2cc736414ee00 If you don't want to wait or would rather use patch-3.6.7-rt18.patch.xz, update PKGBUILD by changing this line:${_basekernel}/patch-${_pkgver}-${_rtpatchver}.patch.xz To this:${_basekernel}/older/patch-${_pkgver}-${_rtpatchver}.patch.xz

commented on 2012-11-26 15:44 (UTC)

The issue I had must have been caused by the fact that I had Intel SpeeStep enabled in BIOS. The same freeze actually happened with 3.4 series rt kernel I tried, but now after disabling it everything is working fine.

hermes14 commented on 2012-11-17 13:32 (UTC)

It's been working flawlessly for a couple of days (no intensive work though), so I'd say it's good for me.

jhernberg commented on 2012-11-17 10:22 (UTC)

It would be really nice if I could get at least 2 confirmations that this package is good, then I could (in good conscience) upload the binary to the archaudio repos.

hermes14 commented on 2012-11-15 14:26 (UTC)

@jhernberg Thanks for all these useful tips, they make the job easier ;)

jhernberg commented on 2012-11-15 14:24 (UTC)

@hermes14 Cool, happy to hear that it works. when using devtools, if you mount /var/lib/archbuild/ on a tmps or use the -r parameter to point to it, it builds in a chroot too.

hermes14 commented on 2012-11-15 14:15 (UTC)

@jhernberg Thanks for the tip, I knew devs use a chroot, but I didn't know how. I'll definitely give it a try. I don't know why I got that error (hope it wasn't a memory failure), since I was able to successfully build the kernel in /dev/shm. I checked out, I didn't go over 10-12% usage during the build process.

jhernberg commented on 2012-11-15 13:28 (UTC)

@hermes14. If you don't know them, install and try the devtools package. It creates a chroot and installs all needed dependencies. It's what the arch devs use to assure that the binaries are correctly built. Build by doing # extra-x86_64-build or extra-i686-build in a directory containing the PKGBUILD script.

hermes14 commented on 2012-11-15 09:49 (UTC)

@jhernberg Didn't check, it would be the first time in years (linux-ck builds fine), I've plenty of RAM. Anyway, I'll try to build it elsewhere.

jhernberg commented on 2012-11-15 09:44 (UTC)

@hermes Did you run out of space on /dev/shm? I built the package with devtools for both x86_64 and i686 before uploading it.

hermes14 commented on 2012-11-15 09:11 (UTC)

I'm getting this error with 3.6.6_rt17-1 (some messages are in italian, sorry, but I think they're quite self-explanatory): In file included from /dev/shm/hermes14/makepkg/src/linux-3.6/arch/x86/include/asm/thread_info.h:22:0, from include/linux/thread_info.h:54, from include/linux/preempt.h:9, from include/linux/spinlock.h:50, from include/linux/seqlock.h:29, from include/linux/time.h:8, from include/linux/stat.h:60, from include/linux/module.h:10, from drivers/net/usb/pegasus.mod.c:1: /dev/shm/hermes14/makepkg/src/linux-3.6/arch/x86/include/asm/processor.h:25:31: fatal error: linux/personality.h: File o directory non esistente compilation terminated. make[1]: *** [drivers/net/usb/pegasus.mod.o] Errore 1 make[1]: *** Attesa dei processi non terminati.... In file included from include/linux/seqlock.h:29:0, from include/linux/time.h:8, from include/linux/stat.h:60, from include/linux/module.h:10, from drivers/net/usb/plusb.mod.c:1: include/linux/spinlock.h:57:31: fatal error: linux/bottom_half.h: File o directory non esistente compilation terminated. make[1]: *** [drivers/net/usb/plusb.mod.o] Errore 1 make: *** [modules] Errore 2

jhernberg commented on 2012-11-09 13:36 (UTC)

There are several archaudio repos, so add the following to your /etc/pacman.conf: [archaudio-production] Server =$repo/$arch

jhernberg commented on 2012-11-09 13:33 (UTC)

I think I'm gonna leave this package here, since I have only 1 report of it being broken (sorry tkln). I guess this is a problem that might appear since we have no formal testing of packages. FWIW, I have left the 3.4.13-rt22 binaries in the archaudio repos. They are (afaik) working very well and also don't have the ext4 bug. If this package breaks your system, add the repo and install the older linux-rt binary from there.

jhernberg commented on 2012-11-08 09:30 (UTC)

Beh, that is bad. Had a feeling it might have been early to switch to 3.6-rt, but on the other hand it is bleeding edge and it needs testing. My aim was however always to keep linux-rt in a production state. Heh, now I don't know what to do, switch back to 3.4-rt (if I can), or keep updating 3.6-rt and hope that this is a special case. On my machines it has days of uptime now, albeit sometimes with funky stuff in dmesg.

commented on 2012-11-08 08:58 (UTC)

Yes, it's console login.

jhernberg commented on 2012-11-08 07:59 (UTC)

Is that in console mode or after starting X? If in X, what gpu do you have? I did find nouveau quite unstable, but both nvidia and intel seem to run fine here.

commented on 2012-11-08 07:21 (UTC)

I just built and installed linux-rt-3.6.5_rt15-2-x86_64. It boots fine but after a minute or so the machine just freezes. It won't even respond to ping anymore. Some times I can't even make it past the login screen, (which comes up nearly instantly due to systemd) before it freezes. I can't find any errors in the logs.

jhernberg commented on 2012-11-04 19:29 (UTC)

Managed to get it up... Hopefully it will work well for all of you, maybe it's a little early, but as it appears to work fine on my systems, and I didn't receive any bug reports, here we go. Please enjoy!

jhernberg commented on 2012-11-04 11:23 (UTC)

Heh, was just gonna upload linux-rt-3.6.5_rt15-1-i686.pkg.tar.xz, but the new aur webif won't let me. Says only lowercase letters are allowed in the file name :) In the mean time, find it at . The lack of comments about the new versions I can only interpret as either no one tried, or no one had any problems. In either case the kernel appears stable on my systems now, so I will upload it to aur when the webif lets me.

Det commented on 2012-11-03 22:09 (UTC)

3.4.17-rt28. Also the ever so promptly released 3.6.5-rt15 fixes some "embarassing typos" in rt14:

jhernberg commented on 2012-11-02 12:51 (UTC)

3.6.4-rt11 still created some problems for me, among other a trainwreck in the soft interrupts taking my hdsp down. In the hope it's getting better here is the next installment for those that want to test:

jhernberg commented on 2012-10-31 20:43 (UTC)

Here is 3.6.4-rt11 if anyone wants to test it:

jhernberg commented on 2012-10-31 12:56 (UTC)

hmm, 3.6.4-rt10 works more or less fine on my systems, have seen some huge latency spikes though. The devs are also talking about slub still having problems. Maybe it would be an idea to create a linux-rt-testing or some such aur package? That way I could leave the well working (and considered by upstream as stable) 3.4-rt as linux-rt and still give you guys 3.6-rt for testing purposes? Did anyone try the 3.6.4-rt10 kernel I put on my dropbox?

Det commented on 2012-10-31 11:53 (UTC)

There's rt11 already:

jhernberg commented on 2012-10-30 22:52 (UTC)

Since there has been quite a few problems with 3.6-rt I'd really appreciate some feedback if the script on my dropbox is good now..

jhernberg commented on 2012-10-30 22:50 (UTC)

I just installed 3.6.4-rt10 on my machines and so far it seems to run well, if anyone wants to help testing the archive is at Have updated the config files and patches to match the official -ARCH kernel and what i consider a good configuration for -rt. Will let it run for a few days, but I think I can update it here on aur soon. Still need to adapt the script itself to some changes in the official script too. Heh, wish I had NUMA to have problems with... FWIW, I hung my system while shutting down yesterday, and when i got it up again, it seems like my clawsmail addressbook was gone and some other problems, but i suppose that can also be completely unrelated to the ext4 stuff, which I've frankly not read enough about to be able to speak about.

jrdnjhntn commented on 2012-10-29 20:42 (UTC)

@Det Non-Uniform Memory Access ~ NOTE: someone else (on the list) had reported issues with 3.6-rt whom was using an *i7* and had numa related errors (plus a patch) on the list. I thought it a shot in the dark that jhernberg may have stumbled across something similar being as he uses an i7 and was having problems with 3.6-rt. ie: it might have been relevant, as could the 3.6 module patches found in linux-rt-ice. (however, do you think asking me if i know what numa is relevant? ...probably not & off topic). @jhernberg I've been under the impression that ext4 bug requires that you are using -nobarrier in /etc/fstab, as well as a particular setup, no? anyway, i haven't been bothered by it :)

Det commented on 2012-10-29 19:41 (UTC)

3.4.15-rt24/3.6.4-rt10 @Ninez, you realize what NUMA is?

jrdnjhntn commented on 2012-10-27 23:34 (UTC)

@jhernberg i was more or less just letting you know about those patches (useful?), but i understand why you might not like to update (AUR) quite yet. :) I also thought it was worth noting that 3.6.x-rt is working (for some people anyway). Note: 3.6.3-rt8 has NUMA and AMD k8 fixes. is it possible that you maybe your were affected by some numa bugs, in 3.6? cheers

jhernberg commented on 2012-10-24 19:56 (UTC)

@nines I haven't tried those patches no, i'll give them a try. Also I installed 3.4.13-rt22 again, due to this:

jrdnjhntn commented on 2012-10-24 12:58 (UTC)

update: 3.6.3-rt6 is working perfectly on my system. I modified linux-rt-ice (ditching the ice stuff and adding my own patch). boots fine, works with nvidia 310.14-rt - tested for 4-5 hours using jackd / wineVSTs / Ardour3 / etc - the latest rt-series seems to be working nicely. @jhernberg - for your 3.6 pkgbuild did you apply the 2 patches found in linux-rt-ice? ~ as i think they may stop the system from freezing. cheerz

jrdnjhntn commented on 2012-10-24 00:12 (UTC)

@jhernberg I had the same issue with 3.6.3-rt6 today - my machine hangs as well (sometimes before i can even startx) ~ AMD Phenom II (quadcore) + Nvidia binary driver. just thought i would pass that along. I'd say sticking with 3.4-rt is the best way to go, until 3.6-rt stabilizes. cheerz

jhernberg commented on 2012-10-22 15:57 (UTC)

Maybe I should add that I had a chat with one of the main devs, and he said there had been some big changes, and that 3.6-rt really is for testing the patch and not for production use.

jhernberg commented on 2012-10-22 11:33 (UTC)

@smoge I'm not quite sure what is wrong. I've created new config files based on arch's 3.6, and done the normal modifications that I think are needed for a well performing rt kernel. It hangs in X on both my intel and my nouveau machines. maybe a local problem, but I really don't think it's a good idea to ship it out like that, when it crashes my test systems, and seeing how people are installing things automatically with yaourt and stuff like that, i'm really afraid to break their systems. I also don't have a lot of time to spend trouble shooting right now. Another reason to be cheerful is that devtools are nroken for me right now, so I can't easily build in a chroot either.

smoge commented on 2012-10-21 17:53 (UTC)

3.4.14-rt23 and 3.6.2-rt4

smoge commented on 2012-10-20 18:39 (UTC)

Hey, jhernberg, what was the problem you referred to in your comment from 21 Sep 2012?

Det commented on 2012-10-15 21:27 (UTC)

Related to this perhaps?: Unflagging, since breaking other people's systems isn't really grounds for a new release.

jhernberg commented on 2012-10-15 16:11 (UTC)

Still no rt patch for 3.6.2-rt. I built 3.6.1-rt1 a few days, but it hangs my machines..

Det commented on 2012-10-15 10:20 (UTC)

No it was a joke you see. 3.6.2's been pulled to [core]:

jhernberg commented on 2012-10-11 21:34 (UTC)

Sorry if you take my comment like that. It was not meant as an attack, just as an information for the people wanting to jump on 3.6.1 already!

Det commented on 2012-10-11 16:21 (UTC)

No need to attack me. I was just being informative.

jhernberg commented on 2012-10-09 19:53 (UTC)

I think my decision will remain to wait with releasing a new major version until Arch's official kernel changes. If for no other reason to take advantage of the testing done, and to sync kernel configuration and patches with it.

Det commented on 2012-10-09 09:55 (UTC)

3.4.12-rt20 and 3.6.1-rt1 are up.

jhernberg commented on 2012-09-21 17:50 (UTC)

Think I got it all working again. Please let me know if there are any problems..

jhernberg commented on 2012-09-16 20:46 (UTC)

@dgbaley27: They don't make patches for all the kernel releases. For the 3.x series the patches released as tarballs have been for 3.0.x, 3.2.x and 3.4.x. I think there is a git repo somewhere with 3.6+rt patches but I wait until they release them as tarballs before making the kernel package/build script. Now if I could only figure out what the devs did to break the package. Didn't have time to really look at it, hopefully I'll have to to see what the official 'linux' build script does sometime soon :(

dgbaley27 commented on 2012-09-16 20:01 (UTC)

My build error was the same as alexdsp, and I got around it as I outlined. Thanks for the info about 3.5/3.6. Is there a technical issue regarding 3.5 or do they not release for every kernel version?

jhernberg commented on 2012-09-16 13:10 (UTC)

Indeed the devs have broken things again :( Let me see if I can fix the package build yet again..

alexdsp commented on 2012-09-16 12:35 (UTC)

Compilation fails .... INSTALL /home/alex/Packages/linux-rt/pkg/linux-rt/lib/firmware/cpia2/stv0672_vp4.bin INSTALL /home/alex/Packages/linux-rt/pkg/linux-rt/lib/firmware/yam/1200.bin DEPMOD 3.4.10-rt18-1-rt ERROR: could not open directory /home/alex/Packages/linux-rt/pkg/linux-rt/lib/modules/3.4.10-rt18-1-rt: No such file or directory FATAL: could not search modules: No such file or directory [alex@arch linux-rt]$ uname -a Linux arch 3.5.3-1-ARCH #1 SMP PREEMPT Sun Aug 26 09:14:51 CEST 2012 x86_64 GNU/Linux

jhernberg commented on 2012-09-16 12:24 (UTC)

@dgbaley27: Do you have an issue with the kernel? I have tried to keep the kernel config (and the entire package) as close as I can to the arch distribution kernel. I have optimized a few settings that as far as I know are important for a -rt kernel, other internet lore that imo is either outdated or erroneous have not been applied. It runs very well indeed on all my test systems, from celeron to i7. What exact problem did you have with /lib->/usr/lib? On my 4 test machines this kernel installs properly, and it also builds correctly in a chroot using devtools (at least last time i built it). Will try to build it again straight away to see if something has changed elsewhere in Arch that I missed... I'm sorry I don't know which git repo to use for the -rt patch, as I use the released tarballs for these kernel builds. What I know is that there won't be a -rt patched 3.5 kerrnel, at some point there will be a 3.6-rt and this package will switch to 3.6, while lts will take over 3.4-rt.

dgbaley27 commented on 2012-09-15 17:08 (UTC)

First, Has any work been done to optimize .config for CONFIG_PREEMPT_RT? I read on that the high resolution time should be enabled and most of ACPI (and APM) should be disabled. Are the .configs provided here identical to [core]/linux with only the addition of CONFIG_PREEMPT_RT? Second, I thought the /lib -> /usr/lib stuff was supposed to be sorted out in this PKGBUILD. Anyway, I got around it by $ cd "$pkgdir" $ mkdir -p usr/lib $ ln -s usr/lib lib At the top of the package() function. Then removing the line toward the bottom wich does a mv from lib to usr/lib. And finally $ cd "$pkgdir" $ rm lib At the end. Finally, Is this patch set maintained as a git branch anywhere? I'd like to get some feel for when 3.5 will be out.

jrdnjhntn commented on 2012-07-17 13:48 (UTC)

thanks jack :) interestingly, i did get it sorted out lastnight - i copied a few depmod related lines from another linux-* pkgbuild. now, this morning i need to look at why nvidia-rt wouldn't install. (nvidia-beta did work on the arch kernel though). cheerz

jhernberg commented on 2012-07-17 12:52 (UTC)

I have updated the script, think the problem was due to

jrdnjhntn commented on 2012-07-17 00:44 (UTC)

anyone else having problems getting linux-rt to compile/install since the kmod/glibc update? this pkgbuild keeps failing in the same spot; DEPMOD 3.4.4-rt13-1-rt ERROR: could not open directory /home/ninez/abs-CustomPKGs/aur-linux-rt/pkg/linux-rt/usr/lib/modules/ No such file or directory FATAL: could not search modules: No such file or directory make: *** [_modinst_post] Error 1 i don't know where it is getting 99.98 from, or why it is adding those lines to the version number. anyone else encounter this?

jrdnjhntn commented on 2012-07-17 00:33 (UTC)

anyone else having problems getting linux-rt to compile/install since the kmod/glibc update? this pkgbuild keeps failing in the same spot; DEPMOD 3.4.4-rt13-1-rt ERROR: could not open directory /home/ninez/abs-CustomPKGs/aur-linux-rt/pkg/linux-rt/usr/lib/modules/ No such file or directory FATAL: could not search modules: No such file or directory make: *** [_modinst_post] Error 1 i don't know where it is getting 99.98 from, or why it is adding those lines to the version number. anyone else encounter this?

capoeira commented on 2012-07-12 15:25 (UTC)

@jhernberg you're right to let it in. though an i7 probably never comes close to ranges where it would have an impact, it's said that newer versions of jack suffer less or nothing from freqscaling. also the module can be blocked for the kernel in grub. and we even have a new software that changes the CPU frequency according to DSP-load: also there are other uses for this kernel than audio. so, disconsider my question. Greets

jhernberg commented on 2012-07-12 12:32 (UTC)

@capoeira, what would you prefer instead? On my i7-2600k I do run the ondemand governor with no negative impact whatsoever on low latency audio or kernel scheduling latency..

capoeira commented on 2012-07-11 16:51 (UTC)

CPU Frequency Scaling: "Since kernel 3.4 the necessary modules are loaded automatically and the recommended ondemand governor is enabled by default." couldn't that be disabled in this Kernel?

jhernberg commented on 2012-06-19 23:03 (UTC)

Thanks smoge, i didn't see that one..

smoge commented on 2012-06-19 05:29 (UTC)

jhernberg, you may change `module-init-tools>=3.16'' to ``kmod''

jhernberg commented on 2012-06-18 17:03 (UTC)

I have removed the out of date flag. Yes there is a 3.4.3 kernel, but no official -rt patch for it yet :)

smoge commented on 2012-06-14 06:12 (UTC)

@jhernberg: I'll continue with linux 3.0, following the changes in Arch linux-lts.

jhernberg commented on 2012-06-13 08:23 (UTC)

Ok, I've updated the package to 3.4.2-rt10. Was planning to track the official arch kernel, but this one is really running great so far, be it with intel or nouveau drivers, so here we go :) I've also removed 3.2-rt from the archaudio repos, and upgraded archaudio-production to 3.4-rt binaries. I've enabled dynamic ticks in this kernel series. Please let me know if you have any problems, especially midi timing wise, since the internet lore is that dynticks should be disabled, even though I can't see any reason for it anymore. @smoge: I guess that means you can pick up 3.2-rt if you want to.

commented on 2012-06-11 15:01 (UTC)

I would still have a need to compile this package myself. I maintain a local diff of config.x86_64 that contains a custom configuration for the linux-rt kernel that I run (CORE2, TRANZPORT, do not compile/include modules that I don't need, etc.). I really appreciate the work you do here for the this aur package as it gives me a foundation PKGBUILD and configs to bases my custom setup on. Please don't abandon this package and, if possible, could you release your 3.4 aur tarball--maybe even maintain 2 aur packages (3.2 and 3.4)? I don't know when you would want to handoff 3.2 to smoge for linux-rt-lts. Thanks.

jhernberg commented on 2012-06-08 16:54 (UTC)

I am wondering though, if I shouldn't make the effort to build nvidia-rt and upload binaries of those too. Think I've fixed my only system with nvidia, so will try to run -rt on that too now.

jhernberg commented on 2012-06-08 16:52 (UTC)

I have uploaded binaaries of 3.2.19_rt30-2 to production and 3.4.1_rt9-1 to preview. So just add the repos and get it directly with pacman. No need for AUR or compiling yourself anymore. I am hoping on the long term that we can get the repos filled with good stuff and stop using AUR for this completely!

capoeira commented on 2012-06-08 14:13 (UTC)

btw. thanks to jhernberg for revitalizing audio repros

capoeira commented on 2012-06-08 14:12 (UTC)

why don't you guys use the audio repros? I haven't expierenced any problem using [preview]

Samsagax commented on 2012-06-08 01:05 (UTC)

@jhernberg: I was just asking "why" :) Seems great to track the official kernel but this package seemed outdated. Btw thanks for maintaining the package

smoge commented on 2012-06-07 23:01 (UTC)

I meant rt30 (AUR had rt29 at that time). this is no such hush, people just want to let you know this.

jhernberg commented on 2012-06-07 22:51 (UTC)

Please take it a little easy guys. just updated the package today, and the patch is still valid... The only 3.2.-rt31 is 3.2.19-rt31-rc1 at the moment... No doubt I'll get to update it tomorrow :) 3.4 is still not here because I wanted to track the official arch kernel. Maybe a bad idea?

Samsagax commented on 2012-06-07 18:01 (UTC)

Why don't you upload here the latest version?

jhernberg commented on 2012-06-05 12:33 (UTC)

i've uploaded 3.4.0-rt8 to [archaudio-preview]

jhernberg commented on 2012-06-02 14:52 (UTC)

I have started adding some packages to the archaudio binary repositories. That means if you add the archaudio repos, you can install the -rt patched kernels with pacman instead of getting the buildscripts from aur and then building and installing them yourselves. See: for more details: For now linux-rt-3.2.18_rt29-1 is available from [archaudio-production] and linux-rt-3.4.0_rt7-1 is available from [archaudio-preview].

jhernberg commented on 2012-05-25 18:04 (UTC)

@smoge, I disabled it because some of the debug options aren't good for a -rt kernel, but i don't know enough about the separate options to tell what can be enabled or not without causing problems. Think it would be better for a production kernel to have it disabled? Why do you need the kernel debugger, does this kernel oops/panic for you? Maybe I should do a linux-rt-debug package too? Would have the standard debugging stuff enabled? Am also in the process of making binary packages for archaudio, so soon you can just add some repos and get the kernel upgraded via pacman instead.

smoge commented on 2012-05-24 22:11 (UTC)

why did you disable DEBUG_KERNEL? I think it's important to first use linux-rt with that enabled for a while.

Samsagax commented on 2012-05-24 18:02 (UTC)

this PKGBUILD won't work. Need to change rt patch release rt27 -> rt29 release 3.2.16 -> 3.2.18

smoge commented on 2012-05-22 19:28 (UTC)

3.4-rt7 is out

jhernberg commented on 2012-05-16 08:40 (UTC)

Think 3.2.17-rt28 will have to wait, because the 3.2.17 kernel has a make error, and I don't want to patch it more or leave any drivers out.. @smoge, Yes that will be merged once 3.4 is out. Most of those changes are for 3.3, that the -rt patch skipped. The configuration will be redone too... Has anyone complained about using dynamic ticks? Was considering doing that for the 3.2 series already, but refrained since some say that it's detrimental for midi (which I don't really use). Think I'll add that for the next configuration too...

smoge commented on 2012-05-14 20:54 (UTC)

Would be a good idea to merge changes from `linux`:

jrdnjhntn commented on 2012-05-03 17:42 (UTC)

for anyone who is interested, the latest nvidia (302.07) driver, works quite well with this kernel. it doesn't suffer the performance regressions that 290.40 had (over 290.35) for many users. The nvidia-rt package can be modified to use 302.07. @jhernberg I'm definitely an nvidia-user with linux-rt ;)

jhernberg commented on 2012-05-03 08:28 (UTC)

Yeah, I've been looking at diffs and am planning a few changes for 3.4. @ smoge, do you also use a nvidia card?

jhernberg commented on 2012-04-22 18:16 (UTC)

@felixonmars Have you tried with nouveau for instance?

felixonmars commented on 2012-04-20 16:34 (UTC)

@jhernberg I only have a laptop with an on-board intel display core. And I did not get any of those problems there. As for the nvidia one, I am getting this issue since linux-RT 3.0 series.

jhernberg commented on 2012-04-20 16:28 (UTC)

@felixonmars. Does it work with another video driver?

felixonmars commented on 2012-04-19 15:18 (UTC)

@jhernberg It's really hard to explain the problem in my poor English, but I'm trying hard to do so: I am using latest version of this kernel with latest nvidia-rt, and it works good till entering KDE. Then every process gets random chance to freeze. I mean, for example, I started a dstat, and it runs correctly for 1 to 30 seconds and then just freezes, Ctrl-C cannot stop it. And the same problem happens randomly on other processes that uses some CPU resource (even really small amount of).

jhernberg commented on 2012-04-19 12:42 (UTC)

For that matter anyone else having problems with this kernel freezing please let me know! Without feedback it's very hard to know if it's good for everyone or not..

jhernberg commented on 2012-04-18 13:05 (UTC)

@smoge Have you checked the difference between the config files with your lts build? I use this on a sandybridge with intel gfx, and a q6600 with nvidia gfx, seems to work fine on both platforms. That said I guess there is plenty that can go wrong :) would be happy to find what is tripping you up. How does the system freeze, totally or just X, etc?

smoge commented on 2012-04-15 02:00 (UTC)

Unfortunately I'm still getting system freezes with this one, not with linux and linux-rt-lts.

commented on 2012-04-04 09:34 (UTC)

@jhernberg Fixed thanks.

jhernberg commented on 2012-04-04 09:13 (UTC)

@parchedtoads They moved the older -rt patches on so when a new patch comes out the package is broken until updated. Try again now.

commented on 2012-04-04 07:44 (UTC)

There's a download error for this package. I've been trying consistently with no luck. Anyone else have the same? [alex@myhost linux-rt]$ makepkg -s PKGBUILD ==> WARNING: Sudo can not be found. Will use su to acquire root privileges. ==> Making package: linux-rt 3.2.12_rt22-1 (Wed Apr 4 11:43:00 MSK 2012) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving Sources... -> Found linux-3.2.tar.xz -> Found patch-3.2.12.xz -> Downloading patch-3.2.12-rt22.patch.xz... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (22) The requested URL returned error: 404 ==> ERROR: Failure while downloading patch-3.2.12-rt22.patch.xz Aborting...

commented on 2012-03-23 19:12 (UTC)

rt21 is outdated, now rt22

jhernberg commented on 2012-03-17 11:43 (UTC)

Just a FYI, I don't intend to update this package to a kernel version that isn't in core yet, so if it takes a few days for a new kernel to enter core, this package will also take a few days. The reason being that the core package is applying various patches, and I would like to keep this patching synced..

Gimmeapill commented on 2012-03-11 18:13 (UTC)

Very good job, thanks for maintaining it

capoeira commented on 2012-02-09 15:43 (UTC)

thanks @felixonmars so i guess it doesn't for me because I have archlinuxfr repro in pacman.conf which includes an old package of linux-rt

felixonmars commented on 2012-02-09 15:36 (UTC)

@jhernberg @capoeira yaourt correctly indicates the package's updates here, my versions are: $ yaourt --version yaourt 1.0.1-4-g8ad2 $ package-query --version package-query 1.0.1-3-gc632

capoeira commented on 2012-02-09 15:33 (UTC)

don't know man. I have no clue how yaourt works. it's not a problem though, as it works, it just doesn't notifie when this package is updated.

jhernberg commented on 2012-02-09 15:08 (UTC)

capoeira: Thinking about it, maybe it's the last 2 lines, the hack i used to get the split package into aur that breaks yaourt?

jhernberg commented on 2012-02-08 20:47 (UTC)

Yes smoge, this time you are indeed right. Didn't have time to look at patch before applying it. Thought that since someone flagged the package as out of date they wanted/needed a new one. Will give myself more time for the next package :)

smoge commented on 2012-02-08 19:16 (UTC)

As I said, that's how they do in rt 3.2.5-rt11 was just a rebase to 3.2.5. `rt12' is an update of the `rt' patch. > and update it when I feel like Update when you think it's correct. Anyway you have 2 weeks before someone disown `your' package.

jhernberg commented on 2012-02-08 18:36 (UTC)

No, I think I'm just gonna ignore when it gets flagged out of date, and update it when I feel like. Sorry never used yaourt, seems far too dangerous and I really prefer to read a script before using it. Something strange happened this time, the old nvidia module in extramodules couldn't be used, so needed to be rebuilt...

capoeira commented on 2012-02-08 17:41 (UTC)

don't let them stress you ;-) one question: yaourt doesn't indicate the updates of this package (using: yaourt -Syu --aur). anybody knows why?

jhernberg commented on 2012-02-08 17:17 (UTC)

Hehe, what happens when you stress me too much guys... really no need to flag as out of date an hour or two after the patch appears. Would really be better to let me take my time and update this package in peace... Off to download -rt12 and build more kernels :) Must be a quality control cycle in effect at the moment :)

smoge commented on 2012-02-07 22:43 (UTC)


capoeira commented on 2012-02-06 22:45 (UTC)

many, many thanks for the update

jhernberg commented on 2012-02-05 21:35 (UTC)

Think the 3.2-rt10 patch was created for 3.2.0, so has been the same for 4 kernel version upgrades now. Ok the .3 to .4 wasn't really an upgrade and went very quickly :) In certain ways running this patch at all is beta testing, but in my experience it has been very stable, so personally I don't really fear upgrading. And finally and most importantly, someone has to test the kernel and the -rt patch, otherwise how will we find the bugs :)

jhernberg commented on 2012-02-05 21:19 (UTC)

What conflicts? The patch applies and the kernel has worked over night on 3 machines here, so I thought I might as well update the package too. And no, the version numbers don't quite work like that. Think the patch is actually called patch-3.2-rt10.patch and has been the same for several kernel releases. There is fuzz when applying the patch.. Think that the stable 3.0 branch does something like that though.. Yeah and this time I was faster than the TUs :) Suppose they leave it a while in testing, and i suppose in the future I will probably run the kernel myself a few days and not release the package until the official kernel has been updated.

smoge commented on 2012-02-05 21:09 (UTC)

You just got lucky that there was no conflicts. But the RT guys, even when there is no change in the RT part of the code, they increase the RT release version. So it actually would be version 3.2.4-rt11, not 3.2.4-rt10, right? Even without change in the `realtime` part of the code. I might be wrong, but if you got no conflicts and if it works, well, I don't know, but you are ahead of mainstream anyway.

wizetek commented on 2012-02-05 21:08 (UTC)

Nice! You're way ahead of the game, jhernberg. I'm awake and enlightened now.

jhernberg commented on 2012-02-05 20:58 (UTC)

Hehe, you guys need to wake up and have a look at :)

wizetek commented on 2012-02-05 19:12 (UTC)

Switch back '_releasever=4' to '_releasever=2' and change 'pkgrel=1' to 'pkgrel=2'.

smoge commented on 2012-02-05 19:01 (UTC)

Something strange: it should be 3.2.2-rt10, not 3.2.4-rt10.

jhernberg commented on 2012-02-05 14:21 (UTC)

I think MajorTom's suggestion seems the best way to work around this aur fail. Also keeps the script quite close to the official script, so easier to follow any changes in it.

smoge commented on 2012-02-05 02:52 (UTC)

Why not: pkgname=('linux-rt') # Build realtime patched -rt kernel # pkgname=('linux-rt' 'linux-rt-headers' 'linux-rt-docs') # Build kernel, headers and doc

wizetek commented on 2012-02-04 23:24 (UTC)

That's because of the multiple "pkgdesc" lines in the PKGBUILD, the last one belonging to the package_linux-rt-docs() function. Check out my simple workaround: Thanks for this package; building right now... So, when is a repo with the binary pkg coming up? ;)

jhernberg commented on 2012-02-04 23:01 (UTC)

Haha, I think I need to continue searching for a way to get this split package onto aur. Thought I did until I saw the package description :) In any case this is indeed the kernel, header and documentation packages...

smoge commented on 2012-02-02 17:01 (UTC)

I think I would show just `Linux 3.2.2-1-rt`?

smoge commented on 2012-01-29 10:59 (UTC)

jhernberg commented on 2012-01-29 03:05 (UTC)

Hang on guys, this is quite an important package :) Just took it over and there are a few things i need to figure out, a 3.2.1-rt or 3.2.2-rt is coming up.

schivmeister commented on 2012-01-27 09:50 (UTC)

Have not been doing justice to this kernel for a long time passing it on to someone else. Orphaning for jhernberg..

capoeira commented on 2012-01-23 19:02 (UTC)

will this be updated to 3.2?

hermes14 commented on 2012-01-20 22:04 (UTC)


Morgan_Cox commented on 2012-01-12 23:31 (UTC)

Hi Just to let you know I have updated the nvidia-rt package now. It should work regardless of how you have compiled the kernel now.

commented on 2012-01-04 20:34 (UTC)

I unflagged this package as being out of date. rt31 is still the latest real-time patchset available. Best, Jeremy

commented on 2011-12-27 21:30 (UTC)

Anybody else experiencing kernel crashes with VST plugins like the ones from TAL? Best, Jeremy

commented on 2011-12-27 20:42 (UTC)

Is there a way to make this compatible with the proprietary nvidia driver. I have trouble getting nouveau to run on my AMD quad-core system. Thanks, JMac

schivmeister commented on 2011-12-06 05:54 (UTC)

When it comes out of RC and becomes stable :)

felixonmars commented on 2011-12-06 04:25 (UTC)

Since 3.2-rc4-rt6 RT already released, I'd like to ask when will this package go 3.2-series? Thanks.

schivmeister commented on 2011-11-28 08:50 (UTC)

Tickless, CONFIG_NO_HZ, i.e "dynticks", or "dynamic ticks", is said to interfere with realtime (though the extent may not be noticeable). That is due to the on-demand nature of this feature - recall that dynamic adjustment of processor frequency also interferes with realtime as it is an on-demand process. In fact, any power-saving feature is rt-unfriendly. Some also say that dynticks does _not_ affect realtime. It is just disabled for the fact that it _may_ interfere. Anyway, can someone check whether this builds in a chroot?

smoge commented on 2011-11-28 08:34 (UTC)

What about the tickless kernel feature (CONFIG_NO_HZ option)?

commented on 2011-11-24 16:29 (UTC)

please edit PKGBUILD and include "older/" in the following path: so it will looks like: Thanks

smoge commented on 2011-11-22 18:59 (UTC)

3.0.9-rt26 is out!

commented on 2011-11-16 15:59 (UTC)

3.0.9 with rt25 - If you get an error downloading rt25 from regarding certificate, just download manually with you browser to your build dir. Added a config option to enable compile of the nvidia driver.

smoge commented on 2011-11-12 18:52 (UTC)

"The 3.0 RT series has reached the production stability point."

feilen commented on 2011-11-11 04:02 (UTC)

Crap, missed MD5sums. patch-3.0.8.bz2 49618d8c7a71549c8870eb709c7d3f81 patch-3.0.8-rt23.patch.gz b11dbce6e4dcd1d38985ef707bbae42d

feilen commented on 2011-11-11 03:57 (UTC) Theoretically fixed PKGBUILD, look for anything obvious that I forgot to change

jeremydei commented on 2011-11-09 04:46 (UTC)

NVIDIA users: So, to be clear. You MUST UNcomment the following lines in the PKGBUILD on your own. This cannot be made part of the package. Afterward you can compile nvidia-rt with no issues. (See also AUR package nvidia-rt). {{{ # WARNING: GPL-INCOMPATIBLE sed -i \ 's/EXPORT_SYMBOL_GPL(migrate_enable);/EXPORT_SYMBOL(migrate_enable);/' \ kernel/sched.c sed -i \ 's/EXPORT_SYMBOL_GPL(migrate_disable);/EXPORT_SYMBOL(migrate_disable);/' \ kernel/sched.c sed -i \ 's/EXPORT_SYMBOL_GPL(__rt_mutex_init);/EXPORT_SYMBOL(__rt_mutex_init);/' \ kernel/rtmutex.c }}}

Morgan_Cox commented on 2011-10-26 09:57 (UTC)

I have updated the nvidia-rt package (you need to uncomment the GPL only symbol lines in the linux-rt PKGBUILD) I can confirm I also needed to chmod +x /usr/src/linux-3.0-rt/scripts/recordmcount chmod +x /usr/src/linux-3.0-rt/scripts/basic/fixdep chmod +x /usr/src/linux-3.0-rt/scripts/mod/modpost

schivmeister commented on 2011-10-23 15:04 (UTC)

Yes, thanks. I'll take a look at why this PKGBUILD reverts all those perms (that are done appropriately in the package function).

jrdnjhntn commented on 2011-10-23 14:38 (UTC)

Schiv, I can also confirm the permission errors that Blackhole mentions, every time that i install Nvidia-beta-all, i also must manually fix the permissions, and the error message appears exactly how blackhole has written it; (error message: permission denied) ...for each or the three scripts listed. the only difference, is that i use the -R flag (recursive) with chmod applied to /usr/src/linux-3.0-rt/scripts (why execute chmod 3 separate times, blackhole?)

blackhole commented on 2011-10-22 15:43 (UTC)

Permission problems. Recompiling for new linux-rt I had to do manually: chmod +x /usr/src/linux-3.0-rt/scripts/recordmcount chmod +x /usr/src/linux-3.0-rt/scripts/basic/fixdep chmod +x /usr/src/linux-3.0-rt/scripts/mod/modpost (Error message: Permission denied)

smoge commented on 2011-10-19 23:39 (UTC)

3.0.7-rt20 is out

schivmeister commented on 2011-10-15 15:27 (UTC)

I meant those lines already exist in the PKGBUILD. In order to fix the permission errors you get I need to know the nature of the problem. Maybe watch out for it next time and keep a copy of the error output. Anyway, with nvidia, you're on your own, unfortunately.

blackhole commented on 2011-10-15 15:09 (UTC)

I have tried your line but without effect. Only chmod +x did the trick. This happens only with nvidia.

schivmeister commented on 2011-10-15 12:39 (UTC)

The reason why I need more information is because the perms are already set up in the PKGBUILD: # fix permissions on scripts dir chmod og-w -R "${pkgdir}/usr/src/linux-${_kernver}/scripts" mkdir -p "${pkgdir}/usr/src/linux-${_kernver}/.tmp_versions" This issue was reported before but we never got to solve it properly.

blackhole commented on 2011-10-15 10:45 (UTC)

It happens with recordmcount and others. I cannot make a complete list since I would have to restart nvidia compilation each time... As a temporay measure I have made a chmod +x to all files in scripts directory. The problem is now that nvidia is compiling without errors but the system will crash at kde start. Only a alt+sysrq+E has given me the possibility, only one time, to enter kde.

schivmeister commented on 2011-10-15 10:30 (UTC)

Changed the from http to ftp.

schivmeister commented on 2011-10-15 10:21 (UTC)

Could you tell us which file or folder that got that permission error? The 'scripts' directory itself or something else in there? And when does this happen? Only when building the nvidia module? Or with all other modules?

blackhole commented on 2011-10-15 10:06 (UTC)

Thank you for the suggestions. However I had to make a chmod +x in the /usr/src/.../scripts direcory to fix some permission denied. Thsi is not happening in the standard kernel.

schivmeister commented on 2011-10-14 22:23 (UTC)

Something happened. I can't access either :/

capoeira commented on 2011-10-14 21:58 (UTC)

when downloading the patch I get: [quote] 2011-10-14 18:55:59 ERRO 403: Forbidden. [/quote]

schivmeister commented on 2011-10-14 08:10 (UTC)

Updated. Generic binaries: I added in relevant parts for the patching of the kernel for nvidia. Uncomment them if you want to build against nvidia.

jrdnjhntn commented on 2011-10-13 22:42 (UTC)

@blackhole AFAIK, it's The linux kernel that has to be patched to allow the Nvidia drivers, not the driver itself. there are 2 files in the source code that must be modified, in a couple of spots, before you compile, otherwise nvidia will fail to install. No patch can be distributed because it violates the GPL. you can however, apply them yourself. there was a discussion on the mailing list about this here; all you have to do, is edit those couple of files to read EXPORT_SYMBOL instead of EXPORT_SYMBOL_GPL (in the source code) then open the patch, and edit it the same way. then, you can install the nvidia drivers, after the kernel is compiled. If nvidia fails to install, find the error and fix it. im using linux-rt with Nvidia-beta-all in AUR. cheerz

blackhole commented on 2011-10-13 17:51 (UTC)

How did you install nvidia? Can I find somewhere a nvidia working package for linux-rt 3.0.6_rt17-1? I have tried to patch here and there but without results. Thank you.

jrdnjhntn commented on 2011-10-13 12:24 (UTC)

Hey Schiv, 3.0.6-rt18 patch is out. I probably won't upgrade yet, as rt17 + Nvidia (not nouveau) is working great over here ;) thanks, for maintaining this package in AUR. cheerz

schivmeister commented on 2011-10-08 22:59 (UTC)

Fixed, thanks.

capoeira commented on 2011-10-08 22:55 (UTC)

there is a typo in the sourcesline: "ftp,archlinux"

schivmeister commented on 2011-10-08 19:30 (UTC)

Updated. Generic binaries at

smoge commented on 2011-10-07 20:00 (UTC)

I'm testing rt17 right now. It seems pretty good, I'm running it without problems so far. Jack with 64 frames/period and 5ms latency, no problems, working great. Let's see if it is stable enough for production, but it seems to be here.

schivmeister commented on 2011-10-06 21:32 (UTC)

Updated. Binaries at the usual place.

schivmeister commented on 2011-09-28 09:35 (UTC)

Oops, sorry about that. Fixed. Binaries tentatively at No idea about the virtualbox issue, sorry. Might want to bring it up to the rt devs.

capoeira commented on 2011-09-28 01:09 (UTC)

config fails md5sum

tritonas00 commented on 2011-09-21 09:40 (UTC)

I installed this kernel (i do audio production) and nvidia-all , all ok but my virtual-box windows 7 virtual machine wont start.It hangs.Even the installer hangs and freezes vbox!I did # rc.d setup vboxdrv and the modules are fine , but i cant use windows 7 in vbox with this kernel. With stock arch kernel i dont have that problem. Any suggestions ?

tritonas00 commented on 2011-09-20 04:37 (UTC)

Working server :

schivmeister commented on 2011-09-15 15:28 (UTC) is still down. Any place else where we could get the kernel sources?

schivmeister commented on 2011-09-03 09:51 (UTC)

Crap..i uploaded that couple of days ago but it looks like slurpy stopped to work and i didn't notice :/ Does anyone know what else works with the new https login?

funkmuscle commented on 2011-08-21 00:50 (UTC)

I gave up and built a new computer with an Intel video card..... Install the rt kernel now..

capoeira commented on 2011-08-19 19:05 (UTC)

Anyone with nvidia-driver tried that "sed"line?

schivmeister commented on 2011-08-19 09:33 (UTC)

Ahh OK but you can still edit the PKGBUILD for the nVidia-specific issue: # enable building proprietary nvidia driver against full rt preemption # WARNING: GPL INCOMPATIBLE #sed -i \ # 's/EXPORT_SYMBOL_GPL(migrate_enable);/EXPORT_SYMBOL(migrate_enable);/' \ # kernel/sched.c Uncomment the sed block.

funkmuscle commented on 2011-08-18 23:15 (UTC)

hey schiv, the only kernel that works for me is the rt kernel as my laptop uses the crappy Intel-HDA sound card... I've tried every kernel but only the rt works(kernel26rt) ngoonee said that nouveau could be the cause as I had to change that as nvidia GPL issues with rt. thanx man... now I need to figure how to use nouveau with linux-rt..

schivmeister commented on 2011-08-18 12:12 (UTC)

Use stock kernel, or -ck, or just -bfs :)

funkmuscle commented on 2011-08-17 21:28 (UTC)

hey schiv, this rt11 is causing major xruns... both this kernel and the rt-ice.. unable to use machine because it's so bad.

schivmeister commented on 2011-08-14 14:08 (UTC)

Just press ENTER, it will select the default, which is n (that's why it's capitalised). Not sure if we'd want y, though. Wasn't this group scheduling a problem before?

commented on 2011-08-14 13:42 (UTC)


capoeira commented on 2011-08-14 13:17 (UTC)

Group scheduling for SCHED_RR/FIFO (RT_GROUP_SCHED) [N/y/?] (NEW)

smoge commented on 2011-08-14 11:35 (UTC)

I think it's rt11 already.

schivmeister commented on 2011-08-13 17:58 (UTC)

@smoge Looks to me like a problem with this realtime kernel, unfortunately. @Morgan_Cox I don't think there would be a point in _not_ having RT_FULL, so I would urge NV users to stick with nouveau for now if they really want to try this out and not patch anything (stay legal). Furthermore, this kernel is not stable at all and the stock linux package would serve your low-latency needs better. From what I see now this is just a testing phase.

smoge commented on 2011-08-13 17:16 (UTC)

I mean make localmodconfig. I'll moving this week, little time for testings.

smoge commented on 2011-08-13 12:58 (UTC)

rt11 is out! @schivmeister: I did `make localconfig', nothing really changed. I will try again in a few days with the other config.

Morgan_Cox commented on 2011-08-13 12:11 (UTC)

schivmeister and anyone who is wanting the Nvidia driver for the new rt kernel :- There is a potential legal issue with distributing a Nvidia driver PKGBUILD for the new rt kernel - I would have to either break the Nvidia License or the GPL... see and for more details. However the driver compiles fine if you compile the rt kernel with - CONFIG_PREEMPT_RTB=y (i.e Basic RT) rather than full rt - CONFIG_PREEMPT_RT_FULL=y as the GPL only symbol is only attached to CONFIG_PREEMPT_RT_FULL (annoyingly..) Hopefully something will be worked out shortly. Its annoying as its technically possible just (perhaps) not legally...

schivmeister commented on 2011-08-12 07:02 (UTC)

@smoge Do one after the other (it shouldn't be too troublesome if you have a powerful machine): 1. Could you please place 'make localmodconfig' in the PKGBUILD (after make prepare)? Make sure to have symlinked /bin/lsmod to /sbin/lsmod. 2. If that does not help, please make menuconfig (or nconfig; uncomment either) and select a preemption model except for full. @willianholtz Yes the nvidia issue is known without a fix yet, probably same for the broadcom.

commented on 2011-08-12 01:35 (UTC)

nvidia and browadcom-wl not work

smoge commented on 2011-08-12 00:02 (UTC)

But with the same issue..

smoge commented on 2011-08-11 22:07 (UTC)

linux-rt9 is out

smoge commented on 2011-08-11 18:23 (UTC)

schivmesiter: no, it did not help much..

schivmeister commented on 2011-08-11 05:58 (UTC)

@smoge Before I provide an alternate kernel/config to test, could you please boot with elevator=cfq (kernel command line) and see if nothing changes?

smoge commented on 2011-08-11 03:22 (UTC)

Compiles and runs here (x86_64 icore7). But performance is really bad, very slow/unresponsive desktop.

akurei commented on 2011-08-10 16:21 (UTC)

Works perfect so far =) Thanks a lot!

schivmeister commented on 2011-08-10 14:24 (UTC)

Please make sure the install creates proper files in /boot. GRUB and symlinks are not important, but what is important is that the files are there so that even if you need to edit your boot configuration it will all just work. I will provide an alternate binary with the stock Arch config and just 1000HZ (critical for MIDI timing, jitter, noise shaping etc), no other change. You can switch to that and try if you suspect any of the changes had an affect.

capoeira commented on 2011-08-10 04:56 (UTC)

my problem is gone, i reseted BIOS, só I guess it is related.

jrdnjhntn commented on 2011-08-10 02:51 (UTC)

compiles and boots fine over here (Arch64 AMD Phenom II X4 965 / 8gig RAM). the only issue i had was that grub2 was not updated, and even when i did update it - the entry for -rt was wrong . it was missing initrd and using /dev/sda instead of UUID. after fixing that, RT booted fine. does nvidia still require patching? and if so, how come there seems to be no pkgbuild for it?

capoeira commented on 2011-08-09 23:42 (UTC)

installed the binary 32bit. first boot my loginmanager (slim) faild to start second boot with elsa loginmanager failed to "wait for udev uevents to be processed" 3d boot loaded to the end, but my USB-wireless-stick didn't conect and than after some seconds system freezed

akurei commented on 2011-08-09 20:29 (UTC)

Building this now. Having great expectations!

schivmeister commented on 2011-08-09 20:20 (UTC) :) I'll keep this package here for now.

schivmeister commented on 2011-08-09 20:15 (UTC)

Built with stock Arch Linux config, except for the following changes: * 1000HZ instead of 300 * Deadline Scheduler is default instead of CFQ * APM is disabled (i686 only; x86_64 non-existent) * Dynamic USB minor allocation disabled ( Two modules had to be taken out as well: Please test. Binary packages for both architectures available at for the meantime.

commented on 2011-08-04 22:17 (UTC)

I got 3.0-rt5/6 compiled on gentoo. But nvidia-drivers failed to build kernel module. So nouveau helped. Though I think it is still very unstable. Or (that seems more real) I still can't configure it properly.

capoeira commented on 2011-08-04 22:12 (UTC)

thanks for the info shiv

schivmeister commented on 2011-08-04 21:54 (UTC)

It's not (just) ice, it's rt. It's not building on my side either. Probably due to the stock arch config that i and most archers copy, 'cause others on different distros have managed to build it. Once linux 3.0 as both software and package (release in [core]) have stabilised I'll investigate this further. No point putting in effort now.

capoeira commented on 2011-08-04 21:44 (UTC)

any news for linux-rt? linux-rt-ice unfortunatly doesn't compile

ngoonee commented on 2011-08-02 08:04 (UTC)

When you do upload linux-rt please test to make sure the nvidia drivers can compile with it. I've uploaded linux-rt-ice but it they don't, as some symbols need to be exported as non-GPL by the kernel. Not sure on the legal implications of that.

schivmeister commented on 2011-07-27 17:50 (UTC)

Whether 3.0-rt would be any better than mainline kernels (since most soft realtime RT code is already in) would need some testing. If it proves useless, I think we don't need an RT kernel anymore :) Currently, there are build failures. Just waiting for the core linux package to stabilise as it's getting a lot of changes ATM.

KriK commented on 2011-07-27 14:06 (UTC)

I will post the new link of linux-rt on and we try to collect more votes)

commented on 2011-07-24 17:41 (UTC)

+1 for linux-rt. But @smoge, I guess those 109 votes will be lost, so people, let's make sure that everyone revotes. I will!

commented on 2011-07-24 16:39 (UTC)

yeah, "linux-rt" would be fine. considering name base "stock" kernel (that currently is in testing repo) simply "linux", so for this package linux-rt would be best. laconically, clear and exhaustive

smoge commented on 2011-07-24 15:18 (UTC)

Would be nice to keep all those +100 votes for inclusion in community.

KriK commented on 2011-07-24 11:36 (UTC)

I think "linux-rt" is better name

schivmeister commented on 2011-07-23 08:54 (UTC)

OK guys, I'll be uploading a new package. It's already been decided that the new base package name would be "linux", so I propose "linux-rt". The only other one I can think of is "linux-realtime". If no-one says anything within a couple of days I'll name it "linux-rt".

smoge commented on 2011-07-23 01:58 (UTC)

Hi Ray, the Linux 3.0-rt1 was released today! =)

hermes14 commented on 2011-06-27 10:33 (UTC)

I can't get 2 fingers actions work on touchpad. It wouldn't be that bad, if it wasn't really too jumpy as long as I graze its surface with more than 1 finger. It often makes me perform unwanted actions like changing desktop or clicking links in browser. synclient reports 2 finger scroll is enabled, but run with -m option states I'm always using 1 finger. On-the-fly changes, both with synclient and xinput, have no effects. Needless to say that with current 2.6.39 everything works like a charm. Any hint?

funkmuscle commented on 2011-05-22 19:12 (UTC)

this kernel only work with the nvidia drivers? I just started using the nouveau as I got tired of updating the nvidia driver every time the kernel changed...

mar77i commented on 2011-05-16 21:19 (UTC)

current doesn't compile here due to with this fix, however it works: <pre> --- kernel26rt/PKGBUILD 2011-04-15 22:10:22.000000000 +0200 +++ kernel26rt_fixed/PKGBUILD 2011-05-16 13:32:41.000000000 +0200 @@ -63,6 +63,9 @@ # Add realtime patch patch -Np1 -i ../patch-$_realkernel$_kernelpatch$_rtpatch + # Fix breakage in + sed -i "s/^\tstruct page \*page;$//1" drivers/net/igbvf/igbvf.h; + # Add our custom logo cp ../logo_linux_clut224.ppm drivers/video/logo/ </pre>

schivmeister commented on 2011-04-15 20:17 (UTC)

I don't think there's much cleanup or sync'ing to do with this minor update (relative to arch's stock kernel), so I've just updated this with Morgan_Cox's changes verbatim. Thanks!

Morgan_Cox commented on 2011-04-11 21:25 (UTC)

I have uploaded a PKGBUILD for This is needed for latest nvidia-rt package. The URL for the kernel patch ( has changed (see PKGBUILD)

smoge commented on 2011-04-11 16:08 (UTC)

new release:

schivmeister commented on 2011-03-07 19:18 (UTC)

Err..that doesn't quite look official. No specific URL to a patch other than a git repo. Unflagging.

mango commented on 2011-03-07 14:12 (UTC)

Det commented on 2011-02-21 11:10 (UTC)

As long as you didn't change 'CONFIG_PREEMPT_RT=y' while at it.

Nareto commented on 2011-02-21 11:01 (UTC)

hello, noob question: if I simply exit in menuconfig without changing any options, will I get a real time capable kernel? (needed for audio)

commented on 2011-02-01 16:53 (UTC)

it don't build with testing/make (3.82-2) with this error: make[1]: *** No rule to make target `/tmp/yaourt-tmp-becks/aur-kernel26rt/pkg/lib/firmware/./', needed by `/tmp/yaourt-tmp-becks/aur-kernel26rt/pkg/lib/firmware/atmsar11.fw'. Stop. make: *** [_modinst_post] Error 2 Aborting... with core/make (3.81-5) build fine thanks

Det commented on 2011-01-08 15:43 (UTC)

Anybody got a clue why are they staying with .33? Didn't really find anything by checking the website. E: Nevermind found this: - where it says (at least) (at the very end) that: "Before you ask: Kernel versions 2.6.34 to 2.6.36 will be left out, the next "Latest Stable" real-time kernel will be based on 2.6.37."

schivmeister commented on 2010-12-21 17:42 (UTC)

Wow great..still 33. Will update soon.

Morgan_Cox commented on 2010-08-28 18:06 (UTC)

I have taken over the nvidia-rt package - just to let you know it is at the latest stable version - 256.44 and will presently work with this kernel (kernel26rt I have only tested x86_64 but it should be fine on i686 also. (not sure how long i'll last at this - pretty busy ... Its also my first submission - contact me if you have issues)

commented on 2010-08-16 08:09 (UTC)

Lol, I know it's difficult but you know the text is right there: Please use a pastebin or email to post PKGBUILDs, patches, or scripts.

ying commented on 2010-04-22 17:28 (UTC)

# Maintainer: Ray Rashif <> # Contributor: timbosa <> # Contributor: Tobias Powalowski <> # Contributor: Thomas Baechler <> pkgname=kernel26rt _kernelname=${pkgname#kernel26} _basekernel=2.6.31 _realkernel=2.6.31 # actual basekernel eg. for rc builds _kernelpatch=.12 _rtpatch=-rt21 pkgver= pkgrel=1 # If sources are rc, old rc, old rt, rc & old rt, old rc & old rt: # rc, rc-old, rt-old, rc-rt-old, all-old or blank for default _source= pkgdesc="The Linux Kernel and modules with realtime preemption" arch=(i686 x86_64) license=('GPL2') url="" backup=(etc/mkinitcpio.d/$pkgname.preset) depends=('kernel26-firmware' 'module-init-tools' 'mkinitcpio>=0.5.20') optdepends=('crda: to set the correct wireless channels of your country') install=$pkgname.install [ "$_source" = "rc" ] && _rc=testing/ [ "$_source" = "rc-old" ] && _rc=testing/v$_realkernel/ [ "$_source" = "rt-old" ] && _rt=older/ [ "$_source" = "rc-rt-old" ] && _rc=testing/ && _rt=older/ [ "$_source" = "all-old" ] && _rc=testing/v$_realkernel/ && _rt=older/ [ -n "$_kernelpatch" ] && \ _kernpatchurl="${_rc}patch-$_realkernel$_kernelpatch.bz2" source=($_realkernel.tar.bz2 $_kernpatchurl${_rt}patch-$_realkernel$_kernelpatch$_rtpatch.bz2 catalyst-rt.patch config config.x86_64 $pkgname.preset logo_linux_clut224.ppm aufs2-base-20090910.patch aufs2-standalone-20090910.patch) build() { KARCH=x86 cd "$srcdir/linux-$_realkernel" # Add upstream patch if [ -n "$_kernelpatch" ]; then patch -Np1 -i ../patch-$_realkernel$_kernelpatch || return 1 fi # Add support for AUFS2 patch -Np1 -i ../aufs2-base-20090910.patch || return 1 patch -Np1 -i ../aufs2-standalone-20090910.patch || return 1 # Add realtime patch patch -Np1 -i ../patch-$_realkernel$_kernelpatch$_rtpatch || return 1 # Add proprietary ATI driver compatibility patch -Np1 -i ../catalyst-rt.patch # Add MBox-2 unofficial patch patch -Np1 -i ../mbox2.patch # Add our custom logo cp ../logo_linux_clut224.ppm drivers/video/logo/ if [ "$CARCH" = "x86_64" ]; then cat ../config.x86_64 > ./.config elif [ "$CARCH" = "i686" ]; then cat ../config > ./.config elif [ -e ../../ ]; then msg "Using previously autosaved config" cat ../../ > ./.config fi sed -i "s|EXTRAVERSION =.*|EXTRAVERSION =|g" Makefile sed -i "s|CONFIG_LOCALVERSION=.*|CONFIG_LOCALVERSION=\"-$_kernelname\"|g" ./.config # load configuration _kernver=$_basekernel-$_kernelname yes "" | make config make menuconfig && cat .config > $startdir/ #make xconfig #make gconfig #make oldconfig # build! make bzImage modules || return 1 mkdir -p "$pkgdir"/{lib/modules,boot} make INSTALL_MOD_PATH="$pkgdir" modules_install || return 1 cp "$pkgdir/boot/System.map26$_kernelname" cp "arch/$KARCH/boot/bzImage" "$pkgdir/boot/vmlinuz26$_kernelname" install -D -m644 Makefile \ "$pkgdir/usr/src/linux-$_kernver/Makefile" install -D -m644 kernel/Makefile \ "$pkgdir/usr/src/linux-$_kernver/kernel/Makefile" install -D -m644 .config \ "$pkgdir/usr/src/linux-$_kernver/.config" mkdir -p "$pkgdir/usr/src/linux-$_kernver/include" for i in acpi asm-{generic,x86} config linux math-emu media net pcmcia scsi sound video; do cp -a include/$i "$pkgdir/usr/src/linux-$_kernver/include/" done # copy arch includes for external modules mkdir -p "$pkgdir/usr/src/linux-$_kernver/arch/x86" cp -a arch/x86/include "$pkgdir/usr/src/linux-$_kernver/arch/x86/" # copy files necessary for later builds, like nvidia and vmware cp Module.symvers "$pkgdir/usr/src/linux-$_kernver" cp -a scripts "$pkgdir/usr/src/linux-$_kernver" # fix permissions on scripts dir chmod og-w -R "$pkgdir/usr/src/linux-$_kernver/scripts" #mkdir -p "$pkgdir/usr/src/linux-$_kernver/.tmp_versions mkdir -p "$pkgdir/usr/src/linux-$_kernver/arch/$KARCH/kernel" cp arch/$KARCH/Makefile "$pkgdir/usr/src/linux-$_kernver/arch/$KARCH/" if [ "$CARCH" = "i686" ]; then cp arch/$KARCH/Makefile_32.cpu "$pkgdir/usr/src/linux-$_kernver/arch/$KARCH/" fi cp arch/$KARCH/kernel/asm-offsets.s "$pkgdir/usr/src/linux-$_kernver/arch/$KARCH/kernel/" # add headers for lirc package mkdir -p "$pkgdir/usr/src/linux-$_kernver/drivers/media/video" cp drivers/media/video/*.h "$pkgdir/usr/src/linux-$_kernver/drivers/media/video/" for i in bt8xx cpia2 cx25840 cx88 em28xx et61x251 pwc saa7134 sn9c102 usbvideo zc0301; do mkdir -p "$pkgdir/usr/src/linux-$_kernver/drivers/media/video/$i" cp -a drivers/media/video/$i/*.h "$pkgdir/usr/src/linux-$_kernver/drivers/media/video/$i" done # add docbook makefile install -Dm644 Documentation/DocBook/Makefile \ "$pkgdir/usr/src/linux-$_kernver/Documentation/DocBook/Makefile" # add dm headers mkdir -p "$pkgdir/usr/src/linux-$_kernver/drivers/md" cp drivers/md/*.h "$pkgdir/usr/src/linux-$_kernver/drivers/md" # add inotify.h mkdir -p "$pkgdir/usr/src/linux-$_kernver/include/linux" cp include/linux/inotify.h "$pkgdir/usr/src/linux-$_kernver/include/linux/" # add wireless headers mkdir -p "$pkgdir/usr/src/linux-$_kernver/net/mac80211/" cp net/mac80211/*.h "$pkgdir/usr/src/linux-$_kernver/net/mac80211/" # add dvb headers for external modules # in reference to: # mkdir -p "$pkgdir/usr/src/linux-$_kernver/drivers/media/dvb/dvb-core" cp drivers/media/dvb/dvb-core/*.h "$pkgdir/usr/src/linux-$_kernver/drivers/media/dvb/dvb-core/" # add dvb headers for external modules # in reference to: # mkdir -p "$pkgdir/usr/src/linux-$_kernver/include/config/dvb/" cp include/config/dvb/*.h "$pkgdir/usr/src/linux-$_kernver/include/config/dvb/" # add dvb headers for # in reference to: # mkdir -p "$pkgdir/usr/src/linux-$_kernver/drivers/media/dvb/frontends/" cp drivers/media/dvb/frontends/lgdt330x.h "$pkgdir/usr/src/linux-$_kernver/drivers/media/dvb/frontends/" cp drivers/media/video/msp3400-driver.h "$pkgdir/usr/src/linux-${_kernver}/drivers/media/dvb/frontends/" # add xfs and shmem for aufs building mkdir -p "$pkgdir/usr/src/linux-$_kernver/fs/xfs" mkdir -p "$pkgdir/usr/src/linux-$_kernver/mm" cp fs/xfs/xfs_sb.h "$pkgdir/usr/src/linux-$_kernver/fs/xfs/xfs_sb.h" # add headers for virtualbox # in reference to: # cp -a include/drm "$pkgdir/usr/src/linux-$_kernver/include/" # add headers for broadcom wl # in reference to: # cp -a include/trace "$pkgdir/usr/src/linux-$_kernver/include/" # add vmlinux cp vmlinux "$pkgdir/usr/src/linux-$_kernver" # copy in Kconfig files for i in `find . -name "Kconfig*"`; do mkdir -p "$pkgdir"/usr/src/linux-$_kernver/`echo $i | sed 's|/Kconfig.*||'` cp $i "$pkgdir/usr/src/linux-$_kernver/$i" done cd "$pkgdir/usr/src/linux-$_kernver/include" && ln -s asm-$KARCH asm # add header for aufs2-util cp -a "$srcdir/linux-$_realkernel/include/asm-generic/bitsperlong.h" "$pkgdir/usr/src/linux-$_kernver/include/asm/" chown -R root.root "$pkgdir/usr/src/linux-$_kernver" find "$pkgdir/usr/src/linux-$_kernver" -type d -exec chmod 755 {} \; cd "$pkgdir/lib/modules/$_kernver" && \ (rm -f source build; ln -sf ../../../usr/src/linux-$_kernver build) # install fallback mkinitcpio.conf file and preset file for kernel install -m644 -D "$srcdir/$pkgname.preset" "$pkgdir/etc/mkinitcpio.d/$pkgname.preset" || return 1 # set correct depmod command for install sed \ -e "s/KERNEL_NAME=.*/KERNEL_NAME=$_kernelname/g" \ -e "s/KERNEL_VERSION=.*/KERNEL_VERSION=$_kernver/g" \ -i "$startdir/$install" sed \ -e "s|source .*|source /etc/mkinitcpio.d/kernel26$_kernelname.kver|g" \ -e "s|default_image=.*|default_image=\"/boot/$pkgname.img\"|g" \ -e "s|fallback_image=.*|fallback_image=\"/boot/$pkgname-fallback.img\"|g" \ -i "$pkgdir/etc/mkinitcpio.d/$pkgname.preset" echo -e "# DO NOT EDIT THIS FILE\nALL_kver='$_kernver'" > "$startdir/pkg/etc/mkinitcpio.d/$pkgname.kver" # remove unneeded architectures rm -rf "$pkgdir"/usr/src/linux-$_kernver/arch/{alpha,arm,arm26,avr32,blackfin,cris,frv,h8300,ia64,m32r,m68k,m68knommu,mips,mn10300,parisc,powerpc,ppc,s390,sh,sh64,sparc,sparc64,um,v850,xtensa} # remove the firmware rm -rf "$pkgdir/lib/firmware" } md5sums=('84c077a37684e4cbfa67b18154390d8a' 'ce365b2c72ad0855e1746a80b7abdade' 'f9489cfa299b89f9d74ba0ced1ee803a' '2a493d1ed820300460abb592b8408ac9' '18da80ac1d41cba0f74cace471862bba' '5e777ff68d871106d9bfa203f5e92750' 'a0921a7e563e7ae2d14c3a0603fa16ad' '6a5a1925501fe20fafd04fdb3cb4f6ed' '1bc4ac3b07e1aa8ef5ee65156b27aa50' '79f7c17c3732f4d18a00eafc010396b3')