Package Details: linux-rt-lts 5.15.40.43.realtime1-1

Git Clone URL: https://aur.archlinux.org/linux-rt-lts.git (read-only, click to copy)
Package Base: linux-rt-lts
Description: The Linux RT LTS kernel and modules
Upstream URL: https://gitlab.archlinux.org/dvzrv/linux-rt-lts/-/commits/v5.15.40.43.realtime1
Licenses: GPL2
Provides: VIRTUALBOX-GUEST-MODULES, WIREGUARD-MODULE
Submitter: smoge
Maintainer: jhernberg (dvzrv, sangy)
Last Packager: dvzrv
Votes: 36
Popularity: 0.000540
First Submitted: 2012-01-29 10:53 (UTC)
Last Updated: 2022-05-19 20:50 (UTC)

Latest Comments

dvzrv commented on 2021-12-18 21:45 (UTC)

FTR: Once upstream linux has released 5.16 and a first stable release of linux-rt in that branch is out, I will update linux-rt-lts to the 5.15 branch (which is the new LTS branch). Currently there are already releases available for 5.15, but I guess it makes sense to wait a little.

jazztickets commented on 2021-09-24 14:21 (UTC)

As a heads up, I hit a strange kernel bug with Nextcloud and this last package update (linux-rt-lts-5.10.65.53.realtime1-1): https://lore.kernel.org/lkml/87ilz1pwaq.fsf@wylie.me.uk/

Ralf_Mardorf commented on 2021-07-28 18:00 (UTC) (edited on 2021-07-29 02:44 (UTC) by Ralf_Mardorf)

You need to edit the PKGBUILD, to use the sources from kernel.org. For testing purpose I used one of my PKGBUILDs, the one I used to build the package for the kernel, that's booted at the moment. I only needed to update the version and to remove a patch. However, the comments are not the right place to teach you, how to write a PKGBUILD. For help consider to use a mailing list.

$ uname -a
Linux archlinux 4.19.193-rt81-0.300-pussytoes #1 SMP PREEMPT RT Mon, 07 Jun 2021 09:13:18 +0200 x86_64 GNU/Linux

Note my PKGBUILDs do not differ much from those provided by dvzrv, actually I compare and align the PKGBUILDs from time to time, trying to stay as close as possible. Apart from the need to use kernel.org as source, I'm in favour of a different versioning pattern and KBUILD_BUILD_TIMESTAMP. Since I stay with 4.19 LTS kernels, there are a few other differences. Maybe the build wouldn't finish, but it started to build, there was just a warning due to the expired key.

Keep in mind that dvzrv provides the LTS kernel, I did not check his source, but at least 5.9 is not a LTS kernel, see kernel.org.

You can name the kernel what ever you want it to name, lts or pussytoes.

$ makepkg -s
==> Making package: linux-rt-pussytoes 5.9.1_rt20-0.300 (Wed 28 Jul 2021 19:29:30 CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Downloading [snip]
==> Verifying source file signatures with gpg...
    linux-5.9.1.tar ... Passed
    patch-5.9.1-rt20.patch ... Passed (WARNING: the key has expired.)
==> WARNING: Warnings have occurred while verifying the signatures.
    Please make sure you really trust them.
[snip]
Prepared linux-rt-pussytoes version 5.9.1-rt20-0.300-pussytoes
==> Starting build()...
  SYSTBL  arch/x86/include/generated/asm/syscalls_32.h
  WRAP    arch/x86/include/generated/uapi/asm/bpf_perf_event.h
  WRAP    arch/x86/include/generated/uapi/asm/errno.h
  WRAP    arch/x86/include/generated/uapi/asm/fcntl.h
  WRAP    arch/x86/include/generated/uapi/asm/ioctl.h
  WRAP    arch/x86/include/generated/uapi/asm/ioctls.h
  WRAP    arch/x86/include/generated/uapi/asm/ipcbuf.h
  WRAP    arch/x86/include/generated/uapi/asm/param.h
  WRAP    arch/x86/include/generated/uapi/asm/poll.h
  WRAP    arch/x86/include/generated/uapi/asm/resource.h
  WRAP    arch/x86/include/generated/uapi/asm/socket.h
  WRAP    arch/x86/include/generated/uapi/asm/sockios.h
  WRAP    arch/x86/include/generated/uapi/asm/termbits.h
  WRAP    arch/x86/include/generated/uapi/asm/termios.h
  WRAP    arch/x86/include/generated/uapi/asm/types.h
  HOSTCC  arch/x86/tools/relocs_32.o
  HOSTCC  arch/x86/tools/relocs_64.o
  HOSTCC  arch/x86/tools/relocs_common.o
  HOSTLD  arch/x86/tools/relocs
  HOSTCC  scripts/dtc/dtc.o
  HOSTCC  scripts/dtc/flattree.o
  HOSTCC  scripts/dtc/fstree.o
  SYSHDR  arch/x86/include/generated/asm/unistd_32_ia32.h
  HOSTCC  scripts/dtc/data.o
  SYSHDR  arch/x86/include/generated/asm/unistd_64_x32.h
^C[snip]Aborted by user! Exiting...

audioarch commented on 2021-07-28 11:16 (UTC)

I want to install the rt-5.9 kernel using the current rt-5.10 PKGBUILD. I edit the pkgver variable of PKGBUILD and run makepkg. The problem of the signature occurs and remains. I have successfully complied and applied rt patch to kernel 5.9 using the traditional compiling method.

Ralf_Mardorf commented on 2021-07-27 15:27 (UTC)

Hi, I'm not sure if I put it clearly. You want to build a lts package for a kernel, that is not a lts kernel. That's no problem, but instead of git+https://gitlab.archlinux.org/dvzrv/linux-rt-lts.git/ you probably need to use kernel.org as source for the kernel and the patch.

Ralf_Mardorf commented on 2021-07-27 14:22 (UTC) (edited on 2021-07-27 14:26 (UTC) by Ralf_Mardorf)

You need to add 57892E705233051337F6FDD105641F175712FA5B to validpgpkeys and download the key before building the package. Note, the key has expired and I assume that the source is kernel.org.

$ xz -cd patch-5.9.1-rt20.patch.xz | gpg2 --verify patch-5.9.1-rt20.patch.sign -
gpg: Signature made Wed 28 Oct 2020 21:04:54 CET
gpg:                using RSA key 57892E705233051337F6FDD105641F175712FA5B
gpg: Good signature from "Sebastian Andrzej Siewior" [expired]
gpg:                 aka "Sebastian Andrzej Siewior <bigeasy@linutronix.de>" [expired]
gpg:                 aka "Sebastian Andrzej Siewior <sebastian@breakpoint.cc>" [expired]
gpg: Note: This key has expired!
Primary key fingerprint: 6425 4695 FFF0 AA44 66CC  19E6 7B96 E816 2A8C F5D1
     Subkey fingerprint: 5789 2E70 5233 0513 37F6  FDD1 0564 1F17 5712 FA5B
$ gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 57892E705233051337F6FDD105641F175712FA5B
gpg: key 7B96E8162A8CF5D1: "Sebastian Andrzej Siewior" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

audioarch commented on 2021-07-27 13:51 (UTC)

How can I download and compile kernel version rt-lts-5.9.1.20? I tried to change the pkgver variable of PKGBUILD of this version and do makepkg. I got this error: linux-rt-lts git repo ... SIGNATURE NOT FOUND ==> ERROR: One or more PGP signatures could not be verified!

blochl commented on 2021-04-18 10:31 (UTC) (edited on 2021-04-18 13:03 (UTC) by blochl)

Is it possible to remove DEBUG_INFO from the config? Looks like it is not used for the package anyway, and can increase the package size dramatically if custom packaging commands are used. Also, looks like it's not an option a regular user would want. If removed via the menu, it produces the following change in the config file:

-CONFIG_DEBUG_INFO=y
-# CONFIG_DEBUG_INFO_REDUCED is not set
-# CONFIG_DEBUG_INFO_COMPRESSED is not set
-# CONFIG_DEBUG_INFO_SPLIT is not set
-CONFIG_DEBUG_INFO_DWARF4=y
-CONFIG_DEBUG_INFO_BTF=y
-# CONFIG_GDB_SCRIPTS is not set
+# CONFIG_DEBUG_INFO is not set

Update - apparently, not: https://bugs.archlinux.org/task/66260

blackhole commented on 2021-04-13 13:43 (UTC)

OK, I have downloaded the necessary files for 5.4.x from git

blackhole commented on 2021-04-13 12:36 (UTC)

Do you have a compiled lts kernel 5.4.x? In your repository I cannot find it no more. (Or eventually the snapshot with the files involved)

dvzrv commented on 2021-04-13 11:46 (UTC)

@blackhole: Yes, my bad. I added the package files without the signatures without noticing. It is fixed now though :)

blackhole commented on 2021-04-13 06:38 (UTC) (edited on 2021-04-13 06:41 (UTC) by blackhole)

Key changed? Installing from respository: error: linux-rt-lts: missing required signature error: linux-rt-lts-headers: missing required signature

dvzrv commented on 2021-04-12 16:01 (UTC)

I have just updated to 5.4.109.55.arch1. Please note, that this will be the last release in the 5.4 series and I will switch to 5.10 shortly.

Mik commented on 2021-03-30 14:12 (UTC)

@maderios indeed I could try wayland but I need to choose another wm in this case. I am used to xorg + fluxbox. I will try this thx.

maderios commented on 2021-03-30 13:17 (UTC)

@Mik May be it comes from your desktop environment? Did you try with Wayland? In my case, i use enlightenment-git (X11). I tried with xfce4 (X11), it works too.

Mik commented on 2021-03-30 12:57 (UTC)

@maderios thx. I will give a try to 4.19. I don't think I need a kernel > 5.4 for my application. This issue is very hard to debug. I don't know if this freeze comes from kernel or Xorg, or chromium...

maderios commented on 2021-03-30 12:12 (UTC)

@Mik I use Firefox and Chromium sometimes (because some admnistration sites support Firefox badly). I use also google-earth-pro. No issue.

Mik commented on 2021-03-30 08:18 (UTC)

@Ralf_Mardorf I'll try 4.19. I am not at home these days, I will do that as soon as possible. @maderios I get these freeze only when I use google chrome on heavy graphic rendering. By instance when I scroll and zoom on google map. What is your browser ?

Thank you

maderios commented on 2021-03-26 20:56 (UTC)

@Mik I use linux-rt-lts 5.4 with intel i915 driver and dkms on a laptop. I have no freeze.

Ralf_Mardorf commented on 2021-03-26 19:32 (UTC)

You shouldn't expect to get rid of Intel GPU issues with kernels > 5.4, see https://wiki.archlinux.org/index.php/intel_graphics#Installation . For my Intel GPU I stay with longterm 4.19 kernels for good reasons:

$ pacman -Q linux-rt{-cornflower,,-securityink,-pussytoes}|cut -d\  -f2
4.19.173_rt72-0.300
4.19.173_rt72-0.1000
4.19.132_rt59-0
4.19.127_rt55-0

Btw. 5.5 isn't longterm, see https://www.kernel.org/ . You likely can expect an upgrade to 5.10, but again, Intel GPUs aren't well supported. Consider to test downgrading to 4.19, too. Just use the latest 4.19 release. I'll upgrade to latest 4.19 soon.

Mik commented on 2021-03-26 19:02 (UTC)

The system freeze with this kernel. Specifically when I use google map (zoom and scroll the map). I have found this thread https://unix.stackexchange.com/questions/563502/system-completly-freezes-often-maybe-chromium-vaapi . This is the related bug report: https://gitlab.freedesktop.org/drm/intel/-/issues/673.

Do you think to upgrade to 5.5 soon ?

dvzrv commented on 2021-02-19 22:20 (UTC)

A heads up to anyone using this kernel: Please modify your /etc/mkinitcpio.conf or create a custom one for this kernel (background).

The current linux-rt-lts is not compatible with zstd compressed initrds, as will be the standard with mkinitcpio >= 30.

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

egarcia commented on 2020-10-03 14:36 (UTC)

Thank you very much for your work!!

papavlos commented on 2020-04-29 17:24 (UTC)

@dvzrv: It's working now. Thanks!

dvzrv commented on 2020-04-29 12:06 (UTC)

@papavlos: I'm on it. My ISP Is super super super super broken right now, so this might take a little while :(

papavlos commented on 2020-04-29 12:02 (UTC) (edited on 2020-04-29 12:06 (UTC) by papavlos)

@dvzrv: Please update .sig files after today's update. Pacman drops errors when doing -yu with [dvzrv] repo in pacman.conf:

error: dvzrv: signature from "David Runge dvzrv@archlinux.org" is invalid

error: failed to update dvzrv (invalid or corrupted database (PGP signature))

vgc commented on 2020-04-08 03:47 (UTC)

@dvzrv: the issue was due to the nvidia-dkms package, with the new version 440.82 it works fine.

vgc commented on 2020-04-07 10:37 (UTC)

@dvzrv: I've update the package but it still doesn't work. Thank you for your time.

dvzrv commented on 2020-04-07 09:12 (UTC)

@vgc: Please check whether the latest version (4.19.106.46-2) fixes this issue for you (it didn't error on me).

vgc commented on 2020-04-07 08:51 (UTC)

@dvzrv: ok, thanks.

dvzrv commented on 2020-04-07 08:41 (UTC)

@vgc: hm, fairly possible that there's something fishy in DKMS for 4.19. I think they will move to 5.4 soon, because that's the new LTS branch. Let's see how that goes.

Meanwhile I'll push an update to this, as I need to fix an issue with upstream's use of python-sphinx.

vgc commented on 2020-04-07 08:34 (UTC)

@dvzrv yes, I have linux-rt-lts-headers. It's a problem that's been happening for about two months, everything was fine before. Same issue occurs with Artix Linux, fresh installation. I noticed that the sixfireusb-dkms package is installed instead, but it doesn't always happen, I've had the same problem with this package in the past few months

dkms status nvidia, 440.64, 5.6.2-arch1-2, x86_64: installed sixfireusb, 0.6.2, 4.19.106-rt46-1-rt-lts, x86_64: installed sixfireusb, 0.6.2, 5.6.2-arch1-2, x86_64: installed

dvzrv commented on 2020-04-06 22:37 (UTC)

@vgc: Hm, just tried on another machine and on initial installation of the packages linux-rt-lts and linux-rt-lts-headers I can reproduce the error message with another DKMS module.

If I explicitely install the two packages again afterwards (pacman -S linux-rt-lts linux-rt-lts-headers) the DKMS module is compiled just fine.

This is quite puzzling. I'll try to figure out why this is happening.

dvzrv commented on 2020-04-06 20:46 (UTC)

@vgc: Hm, I can't reproduce this. Do you have linux-rt-lts-headers installed?

vgc commented on 2020-04-06 19:48 (UTC)

Hi @dvzrv, I use the linux-rt-lts and linux-rt-lts-headers packages from your unofficial repo, but from the latest updates I've the following problem with nvidia-dkms installation:

Your kernel headers for kernel 4.19.106-rt46-1-rt-lts, cannot be found at /usr/lib/modules/4.19.106-rt46-1-rt-lts,/build or /usr/lib/modules/4.19.106-rt46-1-rt-lts,/source. You can use the --kernelsourcedir option to tell DKMS where it's located.

dvzrv commented on 2020-03-11 16:38 (UTC) (edited on 2020-03-11 16:38 (UTC) by dvzrv)

@ph3nix: This package is not OOD. Pleasee read the upstream definition.

(Also, you're probably looking for linux-rt).

francesc.arpi commented on 2019-11-04 12:46 (UTC) (edited on 2019-11-04 15:23 (UTC) by francesc.arpi)

Hi mates.

I've installed kernel from https://pkgbuild.com/~dvzrv/repo/$arch repo, using pacman. But linux-rt-lts.preset for mkinitcpio does not exist.

Can you help me, please?

Thanks!

dvzrv commented on 2019-11-01 13:57 (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 4.19.72.26 in alignment with all vanilla kernels in the main repositories (and will be pushed as soon as the build is complete).

dvzrv commented on 2019-09-12 09:40 (UTC)

@m8D2: This package is not out of date: https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/4.19/older/

phunni commented on 2019-07-30 12:25 (UTC)

Also having checksum problems.

coderkun commented on 2019-07-28 08:26 (UTC)

I can confirm that the checksum for the “config” file does not match.

Ralf_Mardorf commented on 2019-07-25 10:01 (UTC)

The config and it's checksum for 4.19.59_rt23-1 don't fit.

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

Please alos note, that the current TCP based vulnerability in all kernels is only patched in 4.19.52. However, if it's reasonably easy to backport, it might get applied to this kernel (unless it gets updated to a patched version first)!

dvzrv commented on 2019-06-16 12:10 (UTC)

Please note, that once gcc > 9.0 hits [core], it is required to add the following patch to not run into bcache related corruption: https://git.archlinux.org/svntogit/packages.git/tree/trunk/bcache_fix.diff?h=packages/linux-lts

dvzrv commented on 2019-05-14 13:37 (UTC)

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

You can add it to your pacman.conf with:

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

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

Enjoy!

coderkun commented on 2019-05-09 11:28 (UTC) (edited on 2019-05-09 11:31 (UTC) by coderkun)

@simona, I guess you try to install the pre-built binary for this package from my repository, right? For this to work you need to import my GPG key 39E27199A6BEE374 via

$ gpg --recv-keys 39E27199A6BEE374

or manually from https://suruatoel.xyz/coderkun.key. See https://suruatoel.xyz/arch for details.

simona commented on 2019-05-09 11:17 (UTC)

linux-rt-lts-headers: signature from "coderkun olli@coderkun.de" is invalid

jhernberg commented on 2019-03-14 12:50 (UTC)

I've removed the nvidia patch as the problem appears fixed in the nvidia drivers.

jhernberg commented on 2019-02-26 12:19 (UTC)

Restored to the old config file, hopefully all is right now!

It's really getting time to get this config updated, but trying to make it easy for myself failed :) Hopefully we'll get 5.0-rt soon, and then I can move 4.19-rt to -rt-lts instead.

melvinvermeeren commented on 2019-02-22 18:58 (UTC)

Currently the config file is missing several important modules related to iptables, this is only since the most recent commit. Probably the best thing is to undo the removal of the lines in "IP: Netfilter Configuration" and "IPv6: Netfilter Configuration" in the diff of the most recent commit[1]. Myself I got problems because the iptable_nat module was missing.

I do notice regular linux-lts has certain things set to y instead of m for a few of these[2], perhaps this is needed for certain configurations?

Thanks for maintaining so far!

[1] https://aur.archlinux.org/cgit/aur.git/commit/?h=linux-rt-lts&id=c77b586badc9

[2] https://git.archlinux.org/svntogit/packages.git/tree/trunk/config?h=packages/linux-lts

jhernberg commented on 2019-02-21 19:09 (UTC)

Quite a big update of the config file, hope I got it all right :)

Please let me know if I broke something.

kflak commented on 2019-02-13 11:58 (UTC)

This package has been out of date for quite a while now... should I be worried?

Alvarocz commented on 2018-09-19 02:24 (UTC)

Error when building with makepkg

==> applying patch-4.14.69-rt43.patch ... patching file virt/kvm/arm/arm.c ==> ERROR: Se produjo un fallo en prepare(). Cancelando...

jhernberg commented on 2018-08-20 18:07 (UTC)

Sorry for taking so long to do this, was busy with other things and honestly I'm a bit burnt out with packaging. :S Hopefully it works well for everyone!

djpohly commented on 2018-08-01 16:30 (UTC)

The build is fixed upstream by these commits:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ad343a98e74e85aa91d844310e797f96fee6983b

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=854e55ad289ef8888e7991f0ada85d5846f5afb9

You could use those to patch for the time being.

vnen commented on 2018-07-13 23:49 (UTC)

I'm getting the same error as @to7m. Any news on this?

to7m commented on 2018-06-09 13:26 (UTC)

makepkg is failing for me, and apparently this user too: https://bbs.archlinux.org/viewtopic.php?id=237222

Here's the messsage I get:

pager.c: In function ‘pager_preexec’: pager.c:35:12: error: passing argument 2 to restrict-qualified parameter aliases with argument 4 [-Werror=restrict] select(1, &in, NULL, &in, NULL); ^~~ ~~~ cc1: all warnings being treated as errors mv: cannot stat '/home/to7m/.cache/aurman/linux-rt-lts/src/linux-4.9/tools/objtool/.pager.o.tmp': No such file or directory make[4]: [/home/to7m/.cache/aurman/linux-rt-lts/src/linux-4.9/tools/build/Makefile.build:102: /home/to7m/.cache/aurman/linux-rt-lts/src/linux-4.9/tools/objtool/pager.o] Error 1 make[3]: [Makefile:45: /home/to7m/.cache/aurman/linux-rt-lts/src/linux-4.9/tools/objtool/libsubcmd-in.o] Error 2 make[2]: [Makefile:59: /home/to7m/.cache/aurman/linux-rt-lts/src/linux-4.9/tools/objtool/libsubcmd.a] Error 2 make[1]: [Makefile:60: objtool] Error 2 make: *** [Makefile:1623: tools/objtool] Error 2 ==> ERROR: A failure occurred in prepare(). Aborting...

Is it working for others? linux-rt works fine.

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

@Scimmia: This one has two rejects. Please see the linux-rt conversation.

Scimmia commented on 2018-02-05 16:26 (UTC) (edited on 2018-02-05 16:26 (UTC) by Scimmia)

Patches like this only need updated if something they touch changes. If there was no relevant changes from 4.9.76 to 4.9.80, they don't need a new patch. Have you tried it?

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

@Scimmia: No, there is no later patch available, see: https://www.kernel.org/pub/linux/kernel/projects/rt/4.9/

It's impossible to always provide the latest kernel release with a rt patch, as upstream is mostly lagging a bit behind.

Scimmia commented on 2018-02-04 22:33 (UTC)

And you're still out of date even for the 4.9 series

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

But I'll update it to the latest 4.9-rt, have the latest kernel already built for a long time, but have somehow missed updating the AUR :S

jhernberg commented on 2018-02-04 12:04 (UTC) (edited on 2018-02-04 12:30 (UTC) by jhernberg)

@Scimmia: Since you flagged this package as out of date mentioning 4.14 being lts, I suspect you don't understand the thought behind it. This is the stable version of the rt patch that I normally couple to a LTS version of the kernel. At the moment the development version of the RT patch is 4.14-rt, and 4.9-rt is one among several stable versions of the patch. Hopefully we'll soon be moving to more recent versions.

jhernberg commented on 2018-01-09 22:46 (UTC)

@funkmuscle: That's highly unlikely, if not impossible, still don't have a clue what might have happened to your install. I suppose you didn't use devtools to build it, and makepkg to install it? :)

funkmuscle commented on 2018-01-09 20:55 (UTC)

@dvzrv, I was able to boot the kernel with the emergency parameter then reinstalled but the vanilla nd this kernel and it's been working. thanx. is this all to do with the meltdown thing?

jhernberg commented on 2018-01-09 18:48 (UTC)

@mcw: That's because it's a key used to certify the source code downloaded, and not an archlinux package.

mcw commented on 2018-01-06 21:29 (UTC)

That will work (and I have done so), but I wanted to mention it because I thought the keys of the maintainers were supposed to be in archlinux-keyring.

Perhaps I was mistaken, so thanks!

coderkun commented on 2018-01-06 14:32 (UTC)

@mcw import the missing GPG key:

gpg --recv-keys D5AD3963D9E34949

mcw commented on 2018-01-06 14:21 (UTC) (edited on 2018-01-06 14:22 (UTC) by mcw)

For some reason when I build this it is failing with the error:

    patch-4.9.68-rt60.patch ... FAILED (unknown public key D5AD3963D9E34949)
==> ERROR: One or more PGP signatures could not be verified!

My system is otherwise up-to-date, and I have successfully built previous versions on a number of occassions

jhernberg commented on 2018-01-04 17:59 (UTC)

I have linux, linux-lts, linux-rt & linux-rt-lts installed, no such problem.

I did inadvertently leave out the old patchthat restricts the kernels console output while booting, but the only issue I'l aware of.

dvzrv commented on 2018-01-04 17:54 (UTC)

@funkmuscle: What kind of hardware are you running on? Can you correlate this misbehavior with any update to other system related packages (check /var/log/pacman.conf).

Maybe something related to linux-firmware? That would affect both kernels!

funkmuscle commented on 2018-01-03 18:45 (UTC)

dunno what happened here but I have the arch kernel and the rt-lts installed. after upgrading to latest rt-lts, my system died. both kernels panic. I keep the official Arch for this reason. that's if the rt panics, I can boot the official to fix things but this upgrade killed both. any ideas?

jhernberg commented on 2017-12-29 22:58 (UTC)

Finally this one updated too. Please let me know what I broke :)

funkmuscle commented on 2017-10-30 11:51 (UTC)

manjaro's version is 4.9.35_rt25 https://github.com/manjaro/packages-community/tree/master/linux-rt-lts-manjaro Is that version of the rt-lts any different from this seeing that manjaro is Arch based and they use AUR?

jhernberg commented on 2017-05-24 14:15 (UTC)

@ristic: sorry for the late answer. I think your cpu will be using the pstate driver, which afaik can't really be configured. Do you have some problem with it? It doesn't go into deeper C states (shown by i7z)?

ristic commented on 2017-05-19 22:20 (UTC)

Any ideas on how to enable CPU frequency scaling support with this kernel? Is it related to the code patches or kernel configuration? I am running a Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz and according to /proc/cpuinfo and i7z, it is running at the full (without boost) 2.6GHz at all times. I can change the governor to powersave and performance and neither seem to make a difference.

jhernberg commented on 2017-02-19 12:09 (UTC)

FYI, nvidia-dkms should work fine again.

MarcinWieczorek commented on 2016-12-24 13:20 (UTC)

Any progress on the patches?

jhernberg commented on 2016-09-22 18:34 (UTC)

Have asked for the new patches to be uploaded to the older subdir directly too. We used to do this before, and then the script doesn't break at each update, and I get some time to test kernels first ;)

funkmuscle commented on 2016-09-22 14:06 (UTC)

404 issues: 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (22) The requested URL returned error: 404 Not Found ==> ERROR: Failure while downloading https://www.kernel.org/pub/linux/kernel/projects/rt/4.4/patch-4.4.21-rt29.patch.xz Aborting... ==> ERROR: Makepkg was unable to build linux-rt-lts. ==> Restart building linux-rt-lts ? [y/N]

jock-tanner commented on 2016-09-21 07:23 (UTC)

Sorry to bring it up, but the above link to rt-preempt patch 4.4.19-rt27 is now 404ed because the file itself was moved to /older dir. Same things happens regulary, given the structure of rt web archive. I updated the PKGBUILD file locally with the '_pkgver=4.4.21' and '_rtpatchver=rt29' and all went well for me: I was able to boot into my new kernel, 'uname -r' showing '4.4.21-rt29-1-rt-lts'. I also noticed that pgp.mit.edu was down by the moment (“gpg: keyserver receive failed: No keyserver available”), but it might be a false alarm. Given that, thank you jhernberg for all the work that you've done so far, but could you please update the package considering my info?

eiddlechen commented on 2016-07-20 07:21 (UTC) (edited on 2016-07-20 07:25 (UTC) by eiddlechen)

run without sudo: gpg --recv-keys --keyserver hkp://pgp.mit.edu 79BE3E4300411886 gpg --recv-keys --keyserver hkp://pgp.mit.edu 38DBBDC86092693E gpg --recv-keys --keyserver hkp://pgp.mit.edu A2A4FE2EBB2CAFFC

jhernberg commented on 2016-05-23 19:03 (UTC)

@funkmuscle: Hmm, this problem is due to gcc v6 and was fixed in the 4.1 kernel source, but hasn't been backported to older stable kernels. Don't really know how to fix it, tried patching the kernel but the patch doesn't apply ;) I'll see if I can come up with a solution, in the mean time you could downgrade gcc to build it.

funkmuscle commented on 2016-05-22 15:04 (UTC)

I get this error when trying to update: In file included from include/linux/compiler.h:54:0, from include/uapi/linux/stddef.h:1, from include/linux/stddef.h:4, from ./include/uapi/linux/posix_types.h:4, from include/uapi/linux/types.h:13, from include/linux/types.h:5, from include/linux/page-flags.h:8, from kernel/bounds.c:9: include/linux/compiler-gcc.h:106:30: fatal error: linux/compiler-gcc6.h: No such file or directory #include gcc_header(__GNUC__) ^ compilation terminated. Kbuild:35: recipe for target 'kernel/bounds.s' failed make[1]: *** [kernel/bounds.s] Error 1 Makefile:980: recipe for target 'prepare0' failed make: *** [prepare0] Error 2 ==> ERROR: A failure occurred in prepare(). Aborting... The build failed.

jhernberg commented on 2016-03-19 16:35 (UTC)

I've also disowned the nvidia-rt-lts package, as it's not needed, just install linux-rt-lts-headers and the nvidia-dkms package. It will rebuild the needed kernel modules automatically when you upgrade nvidia or a kernel.

jhernberg commented on 2016-03-19 15:54 (UTC)

It's been updated now.

FiyreWyrkz commented on 2016-03-17 05:30 (UTC)

The patch that the PKGBUILD tries to source at https://www.kernel.org/pub/linux/kernel/projects/rt/3.18/patch-3.18.25-rt23.patch.xz is actually located at https://www.kernel.org/pub/linux/kernel/projects/rt/3.18/older/patch-3.18.25-rt23.patch.xz... however I guess I just realized that if I opened the PKGBUILD and read it I would have seen it commented with a # tag.

Fincer commented on 2016-02-25 18:04 (UTC) (edited on 2016-02-25 18:09 (UTC) by Fincer)

The current PKGBUILD script fails. Replace _pkgver=3.18.25 _rtpatchver=rt23 with _pkgver=3.18.27 _rtpatchver=rt25 Also, remove all references to CVE-2016-0728.patch in PKGBUILD. (lines 30 and 76-77). Please remember not to remove ) symbol at line 30. After you've done that, run updpkgsums and makepkg.

jhernberg commented on 2015-11-15 19:23 (UTC)

A headsup, rostedt's key has expired, you'll have to run "gpg --refresh-keys" to update the keys before trying to build this.

jhernberg commented on 2015-11-15 19:22 (UTC)

@erhel: Could you please report this to the linux-rt-users mailinglist?

jhernberg commented on 2015-11-15 19:20 (UTC)

@svictor: you'll have to add the keys to your personal keychain, it has nothing to do with archlinux keychain, see: https://wiki.archlinux.org/index.php/Makepkg#Signature_checking

svictor commented on 2015-11-04 17:07 (UTC)

There seems to be a problem with the signatures : ==> Verifying source file signatures with gpg... linux-3.18.tar ... FAILED (unknown public key 79BE3E4300411886) patch-3.18.21 ... FAILED (unknown public key 38DBBDC86092693E) patch-3.18.21-rt19.patch ... FAILED (unknown public key 48E726E38A87D95D) I just did a pacman -Syu so I suppose I should have the latest keyrings.

rvega commented on 2015-09-06 18:37 (UTC)

This link is broken (404) https://www.kernel.org/pub/linux/kernel/projects/rt/3.18/patch-3.18.20-rt18.patch.xz

erlhel commented on 2015-09-05 16:55 (UTC)

Because of a mystic anomaly in special_insns.h in linux-rt-lts (3.18.17-rt14-1-rt-lts) oss-nonfree(AUR/oss-nonfree 4.2_2011-2) does not find read_cr4 and write_cr4. What I did to make it work was to change read_cr4 and write_cr4 to __read-cr4 and __write_cr4 in osscore.c. The correct change is probably to fix special_insns.h. It is not supposed to have any __write_cr4 or __read-cr4. http://lxr.free-electrons.com/ident?v=3.18&i=__read_cr4 Excerpt from special_insns.h: static inline void write_cr3(unsigned long x) { native_write_cr3(x); } static inline unsigned long __read_cr4(void) { return native_read_cr4(); } static inline unsigned long __read_cr4_safe(void) { return native_read_cr4_safe(); } static inline void __write_cr4(unsigned long x) { native_write_cr4(x); }

jhernberg commented on 2015-08-20 10:45 (UTC)

@kiz: I just built it with extra-x86_64-build from devtools without any problems. Are you possibly running out of diskspace or ram (if using a tmpfs)? FYI, it's also available as a binary from the unsigned repo archaudio-production.

kiz commented on 2015-08-20 08:23 (UTC)

i don't know why, but it always error in my pc: http://pastie.org/10363361

jhernberg commented on 2015-06-07 18:07 (UTC)

@ronjouch: look at this: https://wiki.archlinux.org/index.php/Makepkg#Signature_checking

ronjouch commented on 2015-06-07 15:37 (UTC)

Fails to build with errors below: linux-3.18.tar ... FAILED (unknown public key 79BE3E4300411886) patch-3.18.13 ... FAILED (unknown public key 38DBBDC86092693E) patch-3.18.13-rt10.patch ... FAILED (unknown public key 7B96E8162A8CF5D1) ERROR: One or more PGP signatures could not be verified! Full log at https://bpaste.net/show/9732cb5ce374 . Am new to AUR, does anyone have a suggestion? Is it me or the package?

jhernberg commented on 2015-05-29 11:53 (UTC)

Bumped to 3.18-rt, (has working cpufreq). Have also created a nvidia-rt-lts package.

jhernberg commented on 2015-02-28 20:52 (UTC)

OK, bumped to 3.14-rt. This kernel also has the powersave governor as default. The fix for cpufrq is coming up and I think the next version of 3.14-rt and 3.18-rt will have it.

jhernberg commented on 2015-02-23 17:29 (UTC)

I guess I'm going to move this kernel to 3.14-rt when I find some time. If you have anything against the move, now is the time to speak~ :)

coderkun commented on 2015-01-20 08:59 (UTC)

patch-3.10.64-rt68.patch.xz was again moved to the folder “older” because patch-3.10.65-rt69.patch.xz has been released.

jhernberg commented on 2014-11-16 13:10 (UTC)

@FadeMind: Why do you flag the package out of date when it isn't?

satanselbow commented on 2014-11-08 15:16 (UTC)

rt50 patch url has changed :) https://www.kernel.org/pub/linux/kernel/projects/rt/3.10/older/patch-3.10.47-rt50.patch.xz

jhernberg commented on 2014-08-16 17:43 (UTC)

@totalchaos: I totally forgot to answer this. I run KDE, so possible it's KDE/kwin/opengl related.

totalchaos commented on 2014-07-20 21:08 (UTC)

@jhernberg: I am using Intel-G41 GPU and i don't see any issues. Can you be more specific about the issue? Perhaps i can test how it behave here. Maybe its a window manager specific issue. I mean that once i had this weird behavior on Fluxbox which was not present on Gnome.

jhernberg commented on 2014-07-18 20:11 (UTC)

Just updated to 3.10.47-rt50, and it still doesn't work ok with intel gpus. I also tried downgrading to mesa 9.2 with no change. So I guess the problem is something else, maybe xorg? In any case right now I use linux-rt and that works very well too.

totalchaos commented on 2014-07-09 21:07 (UTC)

"The reason that the archaudio-production repo lags behind a little, is that I use the AUR as a beta test :)" @jhernberg Good to know. And again great job. :)

jhernberg commented on 2014-07-09 09:12 (UTC)

@totalchaos: I forgot, I just updated linux-rt yesterday. The reason that the archaudio-production repo lags behind a little, is that I use the AUR as a beta test :) But also as it's a bit cumbersome to update the repo, and I don't always have the time to do it immediately.

jhernberg commented on 2014-07-09 08:13 (UTC)

@totalchaos: linux-rt-lts on archaudio-production is actually up to date (technically speaking), the only difference between 3.10.39_rt40-1 and 3.10.39_rt40-2 is a change in the path for the rt patch, which is needed every time a new patch comes out. I just updated the buildscript here to make sure that people can build it. I am building linux-rt-lts 10.44-rt46 right now, and hopefully it will be updated later today if all goes to plan.

totalchaos commented on 2014-07-09 05:50 (UTC)

Is the archaudio repository still supported? Because i notice that neither linux-rt-lts nor wine-rt are up to date, comparing to the AUR versions.

jhernberg commented on 2014-07-05 20:28 (UTC)

I haven't had much time, but I can't boot 3.10.44-rt45 at all, no matter what I try. Don't think it's EFI related either. I hope I find some time to trace this down, and if not that the next patch works...:) But in the mean time I did as Det suggested and updated the changed path so at least it builds. Most likely if you use an intel gpu, you'd better use linux-rt instead...:(

Det commented on 2014-07-03 16:26 (UTC)

Could you at least direct the patch to the "older" directory?

jhernberg commented on 2014-06-20 18:47 (UTC)

@david.runge: I haven't booted this for a long time, but it worked on both my hd3000 and my hd4600 when I spun it. But I can confirm that it's broken now on intel gpus. I get screen corruption on both of my 2 intel machines. Suppose some update to the intel graphics stack. 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: https://bugs.archlinux.org/task/33745, but haven't had time to check that hypothesis yet. So really don't know if I should upload it or not :(

dvzrv commented on 2014-06-19 16:59 (UTC)

@jhernberg: This one doesn't work for me. The intel driver refuses to load and X fails. Do I need some special version? :/

jhernberg commented on 2014-05-30 12:27 (UTC)

@totalchaos: You're welcome. Happy that it's useful to people.

totalchaos commented on 2014-05-27 00:00 (UTC)

Thank you vey much, for a job well done. :)

coderkun commented on 2014-03-26 19:45 (UTC)

@jhernberg: Of course, I power my whole band headphone monitoring with this kernel and a MIDI-controller keyboard for live performances ;)

jhernberg commented on 2014-03-26 19:14 (UTC)

You are welcome. I'm happy to know that someone use the kernel at all :)

coderkun commented on 2014-03-26 18:02 (UTC)

Thanks for your great work, jhernberg.

coderkun commented on 2014-03-25 10:18 (UTC)

“patch-3.10.33-rt33.patch.gz” is not available because “patch-3.10.34-rt34.patch.gz” is out.

jhernberg commented on 2013-12-18 13:01 (UTC)

@coderkun: Thanks for the report!

coderkun commented on 2013-12-17 22:05 (UTC)

@jhernberg: 3.10.22_rt19-1 boots fine on my Intel core-i3.

jhernberg commented on 2013-12-17 12:39 (UTC)

@smoge: Have you tried the new kernel, does it work well? Any issues?

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 = http://repos.archaudio.org/$repo/$arch

jhernberg commented on 2013-12-11 19:50 (UTC)

OK, just uploaded 3.10.22-rt19. This kernel has been tested on 2 intel systems so far. One an i7-2600k and the other an old Pentium M laptop, both with intel gpu. Performance very good so far, maximum kernel scheduling latency 92usec on the latop and 45usec on the i7. The kernel is very similar to the -ARCH kernel, with the same debugging options enabled, with the addition of latencytop support. It's configured with a 1000Hz timer and tickless idle support, hopefully making for good power saving on laptops. In case of problems the tickless support can be disabled by passing the "nohz=off" boot parameter to the kernel. I've also changed the default i/o elevator from deadline to cfq, to keep it the same as the -ARCH and -rt kernels. You can change the default back to deadline by using the "elevator=deadline" kernel parameter. To anyone wanting to prioritize the disk i/o for some app, I would recommend investigating the ionice command and it's realtime class. Finally please post any problems you might encounter with this kernel, as otherwise it'll be impossible for me to try to sort them out!

jhernberg commented on 2013-12-10 21:41 (UTC)

@smoge: Well I've always tried for stability :) If you have a problem with linux-rt you ought to tell me, otherwise the problem can't be rectified... I have a kernel that is similar to what my old 3.10-rt was, but I've enabled more debugging and taken a more conservative approach on nohz functionality. I have to say in the few hours uptime that it has now on my system it seems to work very well, unfortunately ymmw as always... I don't know that it differs in any important aspect from your old configuration, but it is more similar to the -ARCH kernel in what not concerns RT. I'll let it run for a while on my system now, and then I'll upload it. I think my approach in the future will be to keep -rt-lts as stable as I can, and -rt is an experiment all in itself, as it's testing all the latest patches to -rt. I'll try to maintain both in binary format in the archaudio-production repo too.

smoge commented on 2013-12-05 17:00 (UTC)

Better as them. What I know is that I play live and I *need* stability, I don't want to loose that. Recent kernels are giving me headaches... From my experience this one was very stable (for almost 2 years!), although recently something might have changed in my machine, it's not the same. Please focus on stability for this one.

jhernberg commented on 2013-12-04 22:30 (UTC)

@smoge: What is the rational behind the -lts kernel config? It's quite different to the distro kernel and I'm wondering why. I thought the idea would be to have a more or less identically configured kernel, just that it would come from a kernel -lts branch?

jhernberg commented on 2013-12-03 17:37 (UTC)

@smoge: Ah, yes that is a good idea!

smoge commented on 2013-12-03 16:09 (UTC)

Thanks! I mean to follow Archlinux linux-lts. I did the config based on Archlinux linux-lts and PlanetCCRMA config files. You may make a diff between linux-lts and linux-rt and see what needs to change to make it realtime.

jhernberg commented on 2013-12-03 16:06 (UTC)

coderkun: I'd take the config file that was used by the -ARCH kernel at the same version number, and change needed options for realtime. That way it'd have the same (mostly) functionality as the main distro kernel.

coderkun commented on 2013-12-03 13:00 (UTC)

@jhernberg: How do you create the config file for rt (-lts)?

jhernberg commented on 2013-12-03 08:18 (UTC)

@smoge: What do you mean by please keep the kernel based on linux-lts?

jhernberg commented on 2013-12-03 08:17 (UTC)

I just adopted the package and I'll try to get 3.10.20-rt17 out soon.

smoge commented on 2013-12-02 19:46 (UTC)

I'll disown the package for now, I won't have time this week. If someone adopt it, please keep the kernel based on linux-lts and test it.

smoge commented on 2013-11-29 15:32 (UTC)

Yes, 3.10.20-rt17 will be the next one, I just need the time.

jhernberg commented on 2013-11-26 19:37 (UTC)

I think 3.10-rt would be the right choice for lts now. 3.10.20-rt17 runs like a train.

coderkun commented on 2013-11-26 18:14 (UTC)

@Det: I would be glad about this, too.

Det commented on 2013-11-26 16:15 (UTC)

Will you be updating to 3.10(.20-rt17)?

Det commented on 2013-11-02 09:17 (UTC)

Please update or disown.

km3k commented on 2013-10-15 18:05 (UTC)

Will this package be moving to the 3.10 kernel like the linux-lts package? The current linux-rt package (3.10.15_rt11-1) works for me, so it might be worth basing this package on that PKGBUILD for now.

commented on 2013-04-26 04:20 (UTC)

3.0.74-rt101

Det commented on 2012-10-29 17:44 (UTC)

3.0.48-rt71

Det commented on 2012-10-09 09:56 (UTC)

3.0.44-rt66

m3thodic commented on 2012-06-14 09:09 (UTC)

Probably want to add: options=(!strip) to the PKGBUILD, in case other kernel modules have to be built from AUR or other sources. Thanks for the update!!

jrdnjhntn commented on 2012-05-03 01:02 (UTC)

pkgbuild not up-to-date and links broken/non-existent

hermes14 commented on 2012-02-13 17:38 (UTC)

@jhernberg: I see, sorry for the misunderstanding. I think you need to have two different version for your nvidia packages, as pointed out by smoge. I didn't find myself a solution for broadcom-wl. @smoge: I mean a PKGBUILD that follows the -ARCH one, like the one jhernberg created.

jhernberg commented on 2012-02-09 20:53 (UTC)

smoge: to clarify, the patch in the nvidia-rt script i wrote http://dl.dropbox.com/u/879835/nvidia-rt-290.10-1.src.tar.gz, would work with both our -rt packages without that gpl symbol stuff that is commented out. I'll leave the excercise to someone else to create the actual packages :)

jhernberg commented on 2012-02-09 20:49 (UTC)

smoge: No i'm not interested in nvidia either. I did however leave a solution on the nvidia-rt page, that means that gpl symbol uglyness could be removed from your build script too. The patch in my source tarball will work with both the -rt and the -rt-lts packages. Guess it will be up to someone else to pick up that ball then and create packages for both -rt and -rt-lts

jhernberg commented on 2012-02-09 19:21 (UTC)

hermes: What I mean is that i have already created it for https://aur.archlinux.org/packages.php?ID=51360. What I wanted to ask smoge is if he has a good idea what to do about nvidia-rt, since it seems impossible for that package to be used both with linux-rt and linux-rt-lts. Sorry if I wasn't clear in my writing.

hermes14 commented on 2012-02-09 18:02 (UTC)

I'm aware of the extramodules directory, and I confirm that certain modules (I'm sure about wl and acpi_call) *sometimes* need to be recompiled. I think it's a good idea, because it keeps the stock modules directory cleaner after all, and also because it follows more closely the official Arch standards. From your previous message I thought you couldn't create it for linux-rt-lts, sorry if I misunderstood. If you're asking whether to create it or not, my vote goes for creating it.

jhernberg commented on 2012-02-09 17:52 (UTC)

hermes: the official linux package creates a directory called /lib/modules/extramodules-3.2-ARCH for out of tree modules, the idea being that users shouldn't have to update them for simple kernel version jumps, like 3.2.4 to 3.2.5. I've done the same in linux-rt creating extramodules-3.2-rt, but i'm personally not sure if this is a good idea or not. Think I've had to recompile the nvidia module already even though in theory it should work.

hermes14 commented on 2012-02-09 16:02 (UTC)

It would be really interesting having a PKGBUILD modeled on the official one! @smoge: please consider it, if you have time and will! @jhernberg: what exactly do you mean with "creating a /lib/modules/extramodules-3.2-rt directory [...] and the linux-rt-lts doesn't"? What about something like mkdir -p "${pkgdir}/lib/modules/extramodules-${_basekernel}${_kernelname:--rt-lts}" (see line 139 of the official PKGBUILD).

jhernberg commented on 2012-02-09 15:00 (UTC)

Something was broken in the old -rt script, I also couldn't compile any out of tree modules due to permission problems in the scripts directory. None of them were executable, which is one reason I gave up on the script and made a new one modeled on the official kernel script. Now it has come to my attention that we have another conflict :) The problem is that I followed the distro kernel's modification creating a /lib/modules/extramodules-3.2-rt directory for the out of tree modules, and the linux-rt-lts doesn't. which probably means that we need a nvidia-rt and a nvidia-rt-lts package which we probably need in any case due to the different kernel versions. Any ideas on what to do with this? Do you have any contact with Morgan Cox, he hasn't replied to email from me?

hermes14 commented on 2012-02-08 19:16 (UTC)

@smoge: No. I'm digging into both linux and linux-rt[-lts] PKGBUILDS and patches, but I still can't find out why, e.g. scripts/recordmcount has 755 permissions in stock kernel but not in -rt[-lts]. The issue came out since compiling acpi_call module failed because of missing execution permissions on some of those scripts.

hermes14 commented on 2012-02-08 13:00 (UTC)

Some scripts in /usr/src/linux-3.0-lts/scripts and below should be chmodded 755. Please compare them with the stock kernel ones. I guess the same applies to the "regular" rt kernel.

capoeira commented on 2012-02-08 01:23 (UTC)

kernel configuration gui pops up during built. i guess this wasn't meant to be like this!?

smoge commented on 2012-02-07 23:08 (UTC)

Updated.

wizetek commented on 2012-02-03 06:19 (UTC)

I have the following suggestions to change config: CONFIG_HID_ACRUX_FF=m -> # CONFIG_HID_ACRUX_FF is not set # CONFIG_NO_HZ is not set -> CONFIG_NO_HZ=y # CONFIG_SCx200 is not set -> CONFIG_SCx200=m CONFIG_SCx200HR_TIMER=m # CONFIG_SCx200_GPIO is not set # CONFIG_SCx200_WDT is not set The 1st line is to prevent 'make config' from stopping and prompting user for input (sets the default "N"). The 2nd and 3rd are common tweaks suggested by the Linux pro audio community. The remaining 3, which are not present in the supplied config, are related to the one above and are set to their defaults. What do you think? Ideally, someone who has been using -rt for a while would try this and compare. Thanks. BTW, you know that sooner or later you'll be asked to provide a repo with a binary pkg? :) ** IMPORTANT DISCLAIMER: It may be evident to some that I am in no way a kernel guru. Just hacking away in a feeble attempt to make things slightly better. **

wizetek commented on 2012-02-02 19:25 (UTC)

Got it. After the fact, I took a look at the AUR comments of 'linux-rt' and saw that a 3.2.2-1 is on the way. Thanks for the package and for the clarification.

smoge commented on 2012-02-02 19:11 (UTC)

No, `linux-rt` is outdated for a long time. This one is the long term support branch of the `linux-rt` project. `linux-rt-lts` will continue to receive bug-fixes in parallel to `linux-rt` in the future.

wizetek commented on 2012-02-02 18:51 (UTC)

Isn't this an up-to-date dup of https://aur.archlinux.org/packages.php?ID=51360 ?

commented on 2012-01-31 21:10 (UTC)

great! I'll try that one right away! :D

capoeira commented on 2012-01-30 19:51 (UTC)

nice

hermes14 commented on 2012-01-30 06:16 (UTC)

Very good idea having an lts rt kernel. Nice job, thank you!