Package Base Details: linux-rt-lts

Git Clone URL: https://aur.archlinux.org/linux-rt-lts.git (read-only)
Submitter: smoge
Maintainer: jhernberg
Last Packager: jhernberg
Votes: 17
Popularity: 0.013824
First Submitted: 2012-01-29 10:53
Last Updated: 2016-08-18 18:51

Latest Comments

eiddlechen commented on 2016-07-20 07:21

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

@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

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

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

It's been updated now.

FiyreWyrkz commented on 2016-03-17 05:30

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

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

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

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

jhernberg commented on 2015-11-15 19:20

@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

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

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

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

@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

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

kiz commented on 2015-08-20 08:20

i don't know why, but it always error in my pc:

==> Entering fakeroot environment...
==> Starting package_linux-rt-lts-headers()...
cp: cannot stat ‘arch//Makefile’: No such file or directory
==> ERROR: A failure occurred in package_linux-rt-lts-headers().
Aborting...
==> ERROR: Makepkg was unable to build linux-rt-lts.
==> Restart building linux-rt-lts-headers ? [y/N]
==> ---------------------------------------------

jhernberg commented on 2015-06-07 18:07

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

ronjouch commented on 2015-06-07 15:37

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

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

jhernberg commented on 2015-02-28 20:52

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

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

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

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

satanselbow commented on 2014-11-08 15:16

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

@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

@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

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

"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

@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

@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

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.

totalchaos commented on 2014-07-09 05:46

Is the archaudio repository still supported?
Because i noticed that neither linux-rt-lts nor wine-rt are up to date.

jhernberg commented on 2014-07-05 20:28

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

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

jhernberg commented on 2014-06-20 18:47

@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

@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

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

totalchaos commented on 2014-05-27 00:00

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

totalchaos commented on 2014-03-31 07:11

The compilation couldn't finished. There were no space left on the divice. I comment out tmpfs-tmp from etc/fstab, but it didn't help. I am stuck again :(

coderkun commented on 2014-03-26 19:45

@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

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

coderkun commented on 2014-03-26 18:02

Thanks for your great work, jhernberg.

coderkun commented on 2014-03-25 10:18

“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

@coderkun: Thanks for the report!

coderkun commented on 2013-12-17 22:05

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

jhernberg commented on 2013-12-17 12:39

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

jhernberg commented on 2013-12-17 12:38

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

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

@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

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

@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

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

smoge commented on 2013-12-03 16:09

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

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

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

jhernberg commented on 2013-12-03 08:18

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

jhernberg commented on 2013-12-03 08:17

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

coderkun commented on 2013-12-03 08:09

@smoge: How do you create the config file for rt?

smoge commented on 2013-12-02 19:46

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

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

jhernberg commented on 2013-11-26 19:37

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

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

Det commented on 2013-11-26 16:15

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

Det commented on 2013-11-02 09:17

Please update or disown.

km3k commented on 2013-10-15 18:05

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.

Anonymous comment on 2013-04-26 04:20

3.0.74-rt101

Det commented on 2012-10-29 17:44

3.0.48-rt71

Det commented on 2012-10-09 09:56

3.0.44-rt66

smoge commented on 2012-06-23 23:32

I'll be traveling next month and I can't update the package. I'll leave it as ``disowned'' so that others can upgrade if necessary.

smoge commented on 2012-06-19 19:08

thanks

m3thodic commented on 2012-06-14 09:09

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

smoge commented on 2012-06-07 04:53

updated to 3.0.33_rt53

smoge commented on 2012-05-24 16:34

updated to 3.0.32_rt52

smoge commented on 2012-05-14 16:59

updated to rt51, merged changes from linux-lts

smoge commented on 2012-05-03 01:12

updated to rt50

Ninez commented on 2012-05-03 01:02

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

smoge commented on 2012-03-17 22:03

Generic x86_64 packages: http://xsounds.org/~archstudio/generic/x86_64/

smoge commented on 2012-03-17 22:02

Generic 86_64 binary packages: http://xsounds.org/~archstudio/generic/x86_64/

smoge commented on 2012-03-17 20:08

Some changes based on `linux-lts`, please report any problems.

smoge commented on 2012-03-02 02:38

Generic x86_64 pkg: https://xsounds.org/~archstudio/generic/x86_64/linux-rt-lts-3.0.23_rt38-1-x86_64.pkg.tar.xz

smoge commented on 2012-02-14 02:03

pkg for 64bit intel corex http://173.230.151.115/~archstudio/x86_64/linux-rt-lts-3.0.20_rt36-1-x86_64.pkg.tar.xz

smoge commented on 2012-02-13 20:14

pkg for 64bit intel corex http://cyclone.cc/~archstudio/x86_64/linux-rt-lts-3.0.20_rt36-1-x86_64.pkg.tar.xz

smoge commented on 2012-02-13 20:12

pkg for corei7: http://cyclone.cc/~archstudio/x86_64

smoge commented on 2012-02-13 18:53

@hermes14: I did a diff between `linux-lts` and `linux-rt-lts`: http://hpaste.org/63623
I see some little differences, I will try to apply them. But did you refer to something specific?

smoge commented on 2012-02-13 18:51

http://hpaste.org/63623

smoge commented on 2012-02-13 18:49

I did a diff between linux-lts and linux-rt-lts, I will try to apply those changes. What I see:

+ sed -ri 's|^(SUBLEVEL =).*|\1|' Makefile
+ rm localversion-rt

+ ## -- docs --##
+ rm -r "${pkgdir}/usr/src/linux-${_kernver}/Documentation"
+ mv Documentation "${pkgdir}/usr/src/linux-${_kernver}"
+ find "${pkgdir}" -type f -exec chmod 444 {} \;
+ find "${pkgdir}" -type d -exec chmod 755 {} \;
+
+ # remove a file already in linux package
+ rm -f "${pkgdir}/usr/src/linux-${_kernver}/Documentation/DocBook/Makefile"

smoge commented on 2012-02-13 18:48

I did a diff between linux-lts and linux-rt-lts, I will try to apply those changes. What I see:

+ sed -ri 's|^(SUBLEVEL =).*|\1|' Makefile
+ rm localversion-rt

- -e "s|ALL_kver=.*|ALL_kver=\"/boot/vmlinuz-${pkgname}\"|g" \
+ -e "s|ALL_kver=.*|ALL_kver=\"/boot/vmlinuz-${pkgname}\"|g" \

- # gzip -9 all modules to save 100MB of space
+ # gzip -9 all modules to safe 100MB of space
+
+ ## -- docs --##
+ rm -r "${pkgdir}/usr/src/linux-${_kernver}/Documentation"
+ mv Documentation "${pkgdir}/usr/src/linux-${_kernver}"
+ find "${pkgdir}" -type f -exec chmod 444 {} \;
+ find "${pkgdir}" -type d -exec chmod 755 {} \;
+
+ # remove a file already in linux package
+ rm -f "${pkgdir}/usr/src/linux-${_kernver}/Documentation/DocBook/Makefile"


hermes14 commented on 2012-02-13 17:38

@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

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

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 20:43

smo

smoge commented on 2012-02-09 20:26

@jhernberg

``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?''

We need a different nvidia package, of course. Like any other nvidia package.
The difference is that nvidia is *not* supported by the rt patch.
I'm not interested in hacking with these, sorry.

smoge commented on 2012-02-09 20:24

@hermes14
> ``It would be really interesting having a PKGBUILD modeled on the official one!''

What official? What exactly?

jhernberg commented on 2012-02-09 19:21

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

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

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

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

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

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

smoge commented on 2012-02-08 17:36

@hermes14: Are you referring to `chmod og-w -R "${pkgdir}/usr/src/linux-${_kernver}/scripts"`?
Or something else? It's the same line in `linux` and `linux-rt-lts` as far as I see.

hermes14 commented on 2012-02-08 13:00

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

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

Updated.

smoge commented on 2012-02-07 22:50

updated

smoge commented on 2012-02-03 19:44

MajorTom: Eventually I will try to upload a binary in [archaudio-preview] (http://archaudio.org/). There is one already optimized for core2 in [archstudio] (http://bbarros.com/archstudio).

I'm using this config for more then a month with no issue whatsoever.

CONFIG_NO_HZ tickless option is kind of controversial since it could be no good for some. There was a discussion in linux-rt about this. Did you test yourself? Try it. Any performance improvements with `CONFIG_NO_HZ` and/or `CONFIG_SCx200HR_TIMER`?

WiZeTeK commented on 2012-02-03 06:19

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

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

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

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

Anonymous comment on 2012-01-31 21:10

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

capoeira commented on 2012-01-30 19:51

nice

hermes14 commented on 2012-01-30 06:16

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