Package Details: linux-rt 4.6.4_rt8-2

Git Clone URL: https://aur.archlinux.org/linux-rt.git (read-only)
Package Base: linux-rt
Description: The Linux-rt kernel and modules
Upstream URL: http://www.kernel.org/
Licenses: GPL2
Submitter: schivmeister
Maintainer: jhernberg
Last Packager: jhernberg
Votes: 130
Popularity: 1.323372
First Submitted: 2011-08-09 20:03
Last Updated: 2016-07-17 11:55

Latest Comments

oberon2007 commented on 2016-07-17 13:09

rt8-patch appears to not be working with virtualbox-dkms modules. See:
https://github.com/manjaro/packages-community/issues/203
http://www.spinics.net/lists/linux-rt-users/msg15527.html

jhernberg commented on 2016-07-17 12:07

@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

@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

@jhernberg maybe you should change the source to the older folder like we did in our PKGBUILD: https://github.com/manjaro/packages-community/blob/master/linux-rt-manjaro/PKGBUILD. Because the newer patch will also get into that folder, not only older patches. :)

jhernberg commented on 2016-07-16 14:11

@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

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

https://www.kernel.org/pub/linux/kernel/projects/rt/4.6/patch-4.6.4-rt6.patch.xz is returning 404. The link in the 4.6 directory seems to be: https://www.kernel.org/pub/linux/kernel/projects/rt/4.6/patch-4.6.4-rt8.patch.xz

Gimmeapill commented on 2016-06-14 21:07

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

jhernberg commented on 2016-06-13 18:47

@abique: Look at this: https://wiki.archlinux.org/index.php/Makepkg#Signature_checking

Do something like $ "gpg --recv-keys 79BE3E4300411886", etc.

abique commented on 2016-06-13 11:47

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

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

@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

Now 4.6.x is out

Gimmeapill commented on 2016-05-04 10:35

@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:
https://wiki.archlinux.org/index.php/Modprobed-db#Using_the_Official_Arch_kernel_PKGBUILD

jhernberg commented on 2016-05-04 10:21

@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

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

jhernberg commented on 2016-04-08 11:10

@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

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

jhernberg commented on 2016-04-07 20:15

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

@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

@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

@Gimmeapill: Check out this paper: http://www.grame.fr/ressources/publications/Timing.pdf

ronjouch commented on 2016-04-06 03:30

@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

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

yagojrocket commented on 2016-04-05 13:18

@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

@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

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

jhernberg commented on 2016-04-05 11:25

@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

@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

@jhernberg: FYI, I reported it a while ago to the quickscan author (on the basis of the current linux-rt settings):
https://github.com/raboof/realtimeconfigquickscan/issues/4

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

@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

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

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/Makefile.build:258: 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/Makefile.build:403: recipe for target 'drivers/crypto/qat/qat_common' failed
make[3]: *** [drivers/crypto/qat/qat_common] Error 2
scripts/Makefile.build:403: 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/Makefile.build:403: 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

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

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

Thanks very much.

Noroimusha commented on 2016-03-27 12:11

@mitchk:
hi, you might find this Archwiki chapter interesting:
https://wiki.archlinux.org/index.php/Makepkg#Signature_checking .

mitchk commented on 2016-03-26 18:02

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

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

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

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

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

jhernberg commented on 2016-03-05 11:06

@dvzrv: Try this: https://www.dropbox.com/s/k5hi64mf31ed2c5/linux-rt-dev-4.4.3_rt9-1.src.tar.gz 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 kernel.org 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

@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

Here is a buildscript to a 4.4.1-rt kernel: https://www.dropbox.com/s/3iy8zqt5f6fak5q/linux-rt-dev-4.4.1_rt6-1.src.tar.gz?dl=0
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

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

If someone wants to test 4.4.-rt3 the source package is here: https://www.dropbox.com/s/tgn8xzbmxwvfyur/linux-rt-4.4_rt3-1.src.tar.gz?dl=0

Seems to work fine so far (very limited testing).

jhernberg commented on 2016-01-24 11:57

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

@hdante: Look at this: https://wiki.archlinux.org/index.php/Makepkg#Signature_checking

Do something like $ "gpg --recv-keys 79BE3E4300411886", etc.

jhernberg commented on 2016-01-22 20:36

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

hdante commented on 2016-01-21 20:52

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

it would be probably good to add this patch: https://projects.archlinux.org/svntogit/packages.git/plain/trunk/CVE-2016-0728.patch?h=packages/linux

jankoppe commented on 2016-01-14 15:14

@jhernberg: did not see that. Sorry then!

jhernberg commented on 2016-01-12 10:14

@jankoppe: So far just a rebase to v4.4-rc6: see: https://lkml.org/lkml/2015/12/23/440

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

@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

@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

@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

@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

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

@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

@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

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

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

@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

@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

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

@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

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

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

capoeira commented on 2015-08-04 16:08

@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

@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

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

@jhernberg I have no clue how to aply the fix

jhernberg commented on 2015-07-01 10:31

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

capoeira commented on 2015-06-29 11:57

well, I seam to be the only one with Arch using HDMI with HDA Intel anyways: https://bbs.archlinux.org/viewtopic.php?id=196784
only found Ubunters with the same problem.

jhernberg commented on 2015-06-27 16:15

@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

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

jhernberg commented on 2015-06-26 19:17

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

capoeira commented on 2015-06-25 21:01

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

Continuing the discussion started there
https://aur.archlinux.org/packages/linux-rt/

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

@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 https://bugs.archlinux.org/task/44286

funkmuscle commented on 2015-06-07 12:09

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

thanks

jhernberg commented on 2015-06-03 17:11

@vania: Look at this: https://wiki.archlinux.org/index.php/Makepkg#Signature_checking

Do something like $ "gpg --recv-keys 79BE3E4300411886", etc.

jhernberg commented on 2015-06-03 17:10

jhernberg commented on 2015-06-03 17:09

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

vania commented on 2015-06-03 15:46

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

@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

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

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

@funkmuscle: Guess you are also affected by this bug: https://bugs.archlinux.org/task/44286
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

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

@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

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

jhernberg commented on 2015-05-29 08:39

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

@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

nice,
I also found this repro: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#coderkun-aur-audio
why don't you work together?

jhernberg commented on 2015-05-28 16:06

FWIW, I've updated the archaudio-production repo, and added nvidia-rt too.

funkmuscle commented on 2015-05-28 14:44

@blackhole: that worked.. thanx

blackhole commented on 2015-05-28 14:37

This was my method:
1) add
keyserver hkp://pgp.mit.edu:11371
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

doing that guys but this is what happens:

gpg: keyserver receive failed: No keyserver available

jhernberg commented on 2015-05-27 22:51

@funkmuscle: see: https://wiki.archlinux.org/index.php/Makepkg#Signature_checking

capoeira commented on 2015-05-27 21:22

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

@capoeira: explain to me how cap.. I want this don't right.

capoeira commented on 2015-05-27 20:47

@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

@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: https://wiki.archlinux.org/index.php/Makepkg
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

@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: https://wiki.archlinux.org/index.php/Makepkg

capoeira commented on 2015-05-25 01:17

getting 3 unknown public key messages

jhernberg commented on 2015-05-23 08:40

@Gimmeapill: Great news, then we'll ignore the problem and hope that it just got fixed :)

Gimmeapill commented on 2015-05-23 07:00

@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

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

@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 (https://wiki.archlinux.org/index.php/Kdump) and get a proper crash dump, but I lacked time until now...

jhernberg commented on 2015-04-29 08:17

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

https://dl.dropboxusercontent.com/u/879835/linux-rt-3.18.9_rt5-2-x86_64.pkg.tar.xz
https://dl.dropboxusercontent.com/u/879835/linux-rt-docs-3.18.9_rt5-2-x86_64.pkg.tar.xz
https://dl.dropboxusercontent.com/u/879835/linux-rt-headers-3.18.9_rt5-2-x86_64.pkg.tar.xz

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 irc.oftc.net.

Gimmeapill commented on 2015-04-23 21:04

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

@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

@Gimmeapill: Does it cold boot ok, and just have problem with shutdown/reboot?

jhernberg commented on 2015-04-22 07:25

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

Nope - that didnt help. Getting back to stock kernel for the time being

Gimmeapill commented on 2015-04-21 07:54

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

@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: https://wiki.archlinux.org/index.php/Makepkg#Signature_checking

ilkyest commented on 2015-04-18 18:59

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

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: https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt

dvzrv commented on 2015-03-25 14:05

@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 (https://bugs.archlinux.org/task/2985).
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

@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

And that's done, too: https://aur.archlinux.org/packages/vhba-module-rt/

dvzrv commented on 2015-03-24 15:15

@jhernberg: No need to. It's done: https://aur.archlinux.org/packages/bbswitch-rt/
@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.

Anonymous comment on 2015-03-24 14:43

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

@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

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

Anonymous comment on 2015-03-23 12:26

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 ?

Anonymous comment on 2015-03-23 12:25

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

With working cpufreq ! :)

funkmuscle commented on 2015-03-01 15:47

@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

I don't use yaourt, so don't know the specifics, but hopefully this will help: https://wiki.archlinux.org/index.php/makepkg#Signature_checking

funkmuscle commented on 2015-03-01 02:51

@jhernberg, the same way I did the last one, yaourt -S

jhernberg commented on 2015-02-28 18:15

@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

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

Yes! At least the first version of the patch is in kernel 3.18

jhernberg commented on 2015-02-23 17:25

@blackhole: Does 3.18-rt help you with DSD?

jhernberg commented on 2015-02-23 17:24

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

Sorry for the delay, but I have contacted the author of the patches.
The problem is that the new patches (https://github.com/lintweaker/xmos-native-dsd/tree/master/SRPMS/patches/kernel, 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 http://www.tophifi.it/ftp/packages/linux-rt-dsd.zip

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

@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

I ma trying to apply the DSD native patches to this kernel
I am using these:
https://github.com/lintweaker/xmos-native-dsd/tree/master/SRPMS/patches/kernel
(the official but not updated patches are here:
https://github.com/lintweaker/xmos-native-dsd/tree/master/kernel-patches)

I have made an archive with all the patches and already modified PKGBUILD
www.tophifi.it/ftp/packages/linux-rt-dsd.zip

If you have time...please take a look. There are some problems. Thank you.

blackhole commented on 2015-01-26 11:25

I am trying to apply the DSD native patches to this kernel
I am using these:
https://github.com/lintweaker/xmos-native-dsd/tree/master/SRPMS/patches/kernel
(the official but not updated patches are here:
https://github.com/lintweaker/xmos-native-dsd/tree/master/kernel-patches)

I have made an archive with all the patches and already modified PKGBUILD
www.tophifi.it/ftp/packages/linux-rt-dsd.zip

If you have time...please take a look. Thank you.

blackhole commented on 2015-01-26 11:25

I ma trying to apply the DSD native patches to this kernel
I am using these:
https://github.com/lintweaker/xmos-native-dsd/tree/master/SRPMS/patches/kernel
(the official but not updated patches are here:
https://github.com/lintweaker/xmos-native-dsd/tree/master/kernel-patches)

I have made an archive with all the patches and already modified PKGBUILD
www.tophifi.it/ftp/packages/linux-rt-dsd.zip

If you have time...please take a look. Thank you.

blackhole commented on 2015-01-23 16:20

updated new up-to-date package for nvidia here:

https://aur.archlinux.org/packages/nvidia-last-rt/
https://aur.archlinux.org/packages/nvidia-340xx-rt/

blackhole commented on 2015-01-23 16:18

updated new up-to-date package for nvidia here
https://aur.archlinux.org/packages/nvidia-last-rt/

jmx commented on 2015-01-20 11:07

Sorry, I meant 3.14.29-rt26 is out...

jmx commented on 2015-01-20 11:06

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

Now 3.14.28-rt25 is out!

cptiglo commented on 2015-01-17 13:15

The http address for the realtime patch is no longer valid!

Gimmeapill commented on 2014-12-18 22:59

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

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:
https://wiki.archlinux.org/index.php/Intel_graphics

mlerota commented on 2014-12-14 12:40

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

@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

@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

@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

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

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

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

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

jhernberg commented on 2014-11-16 13:07

@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

I would like to let you know that I have sucessfully applied the kernel patches at
https://github.com/lintweaker/xmos-native-dsd
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

@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

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

@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

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.

Ninez commented on 2014-11-01 23:05

@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

I forgot, thanks @Ninez for finding the patch to fix NVIDIA hangs.

jhernberg commented on 2014-11-01 16:49

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

@hyshka: Never tried, is it broken?

hyshka commented on 2014-10-25 18:31

Has anyone gotten linux-rt running with BTRFS?

jhernberg commented on 2014-10-22 09:23

@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

@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

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)
http://en.community.dell.com/cfs-file/__key/telligent-evolution-components-attachments/13-4491-00-00-20-22-77-64/Controlling_5F00_Processor_5F00_C_2D00_State_5F00_Usage_5F00_in_5F00_Linux_5F00_v1.1_5F00_Nov2013.pdf

jhernberg commented on 2014-10-20 20:22

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 = os.open('/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

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

@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

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

@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

I agree with performance governor.

blackhole commented on 2014-10-15 15:33

I agree with performance governor.

jhernberg commented on 2014-10-15 13:10

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

oscilloscope is part of the tuna application just released on AUR!

Old but interesting:

https://www.osadl.org/Single-View.111+M52212cb1379.0.html

jhernberg commented on 2014-10-13 18:51

@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

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 www.tophifi.it

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

@Nognir: The problem is in BTRFS. I could not run any rt kernel with BTRFS.

jhernberg commented on 2014-09-29 15:14

@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 https://aur.archlinux.org/packages/linux-l-pa/ 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

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

@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 :)

Ninez commented on 2014-08-17 17:37

@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

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

Ninez commented on 2014-08-17 13:40

@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

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

Ninez commented on 2014-08-16 17:50

@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

@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 :)

Ninez commented on 2014-08-16 12:05

@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

@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 :(

Ninez commented on 2014-08-12 16:51

@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: https://aur.archlinux.org/packages/tuna/ ... 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]: https://aur.archlinux.org/packages/tuned/ ... 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

@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

_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

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

@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

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

Some potentially bad news on rt kernel development

http://article.gmane.org/gmane.linux.rt.user/12370

- 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

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

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

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

@ djimenez: I mean your "non standard" way of building linux-rt.

jhernberg commented on 2014-07-06 11:59

@ 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

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

@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

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

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

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: 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 :(

jhernberg commented on 2014-06-20 18:28

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

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?

Ninez commented on 2014-06-20 14:04

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

Ninez commented on 2014-06-20 14:04

@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

@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

@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

@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

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

@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

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

Ninez commented on 2014-05-29 11:49

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

Anonymous comment on 2014-05-29 11:35

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 !

Ninez commented on 2014-05-29 11:19

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

Anonymous comment on 2014-05-29 09:58

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 ?

Ninez commented on 2014-05-26 19:56

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.

http://sourceforge.net/projects/l-proaudio/files/linux-l-pa-headers-3.14.4_rt5-3-x86_64.pkg.tar.xz/download
http://sourceforge.net/projects/l-proaudio/files/linux-l-pa-docs-3.14.4_rt5-3-x86_64.pkg.tar.xz/download
http://sourceforge.net/projects/l-proaudio/files/linux-l-pa-3.14.4_rt5-3-x86_64.pkg.tar.xz/download

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; https://aur.archlinux.org/packages/nvidia-l-pa/

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

Ninez commented on 2014-05-26 14:44

@earn - Could you please try debugging boot? https://wiki.archlinux.org/index.php/Boot_debugging ... 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; https://aur.archlinux.org/packages/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

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

Anonymous comment on 2014-05-26 13:23

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

@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

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

@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

Ok.
Is there a way to install linux-rt 3.14.3_rt5-1 and keep the older realtime kernel?

blackhole commented on 2014-05-26 11:12

Ok.
Is there a way to install linux-rt 3.14.3_rt5-1 and keep the older relatime kernel?

jhernberg commented on 2014-05-24 16:47

@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

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

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

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.

Ninez commented on 2014-05-12 02:22

@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; https://aur.archlinux.org/packages/tuned-git/]. 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.



Ninez commented on 2014-05-11 02:46

@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

@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:28

@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:26

@Nines, 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

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

Ninez commented on 2014-05-07 23:19

@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

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

Ninez commented on 2014-05-07 18:32

@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; http://www.phoronix.com/scan.php?page=news_item&px=MTY4NDE ... maybe your problem is related?

Ninez commented on 2014-05-07 18:32

@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; http://www.phoronix.com/scan.php?page=news_item&px=MTY4NDE ... maybe your problem is related?








jhernberg commented on 2014-05-07 18:00

@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

@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 :)

Ninez commented on 2014-05-07 13:53

@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; https://lkml.org/lkml/2014/4/17/377]... 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

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

Ninez commented on 2014-05-07 08:11

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

Ninez commented on 2014-05-07 07:41

@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

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

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

Ninez commented on 2014-04-15 15:19

@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; https://devtalk.nvidia.com/default/topic/729914/linux/__rt_mutex_init-has-changed-to-export_symbol_gpl-causing-337-12-to-not-compile-on-3-14-rt-/ 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

Ninez commented on 2014-04-13 16:05

@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; http://pastebin.com/PF2reXX7].

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

@daniel.appelt That was it. Thanks :)

daniel.appelt commented on 2014-03-30 14:01

@totalchaos: you are maybe missing the patch package which is part of the base-devel group: https://wiki.archlinux.org/index.php/AUR#Getting_started

totalchaos commented on 2014-03-29 21:03

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

Pastebin?

jhernberg commented on 2014-03-11 23:05

@mindhack: let's see how this turns out :)

This is the diff between the distro and the rt kernel configs (x86_64)

Some of the changes I've made, some are just due to differences between vanilla and rt, and some I frankly don't know why they are different, but maybe fit to the second point...:)

--- config.disto 2014-03-11 23:53:06.622217356 +0100
+++ config.x86_64 2014-01-26 12:34:44.756999403 +0100
@@ -1,6 +1,6 @@
#
# Automatically generated file; DO NOT EDIT.
-# Linux/x86 3.12.7-1 Kernel Configuration
+# Linux/x86 3.12.8 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
@@ -19,7 +19,8 @@
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
-CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_RWSEM_GENERIC_SPINLOCK=y
+# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
@@ -51,7 +52,7 @@
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
-CONFIG_LOCALVERSION="-ARCH"
+CONFIG_LOCALVERSION="-rt"
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
@@ -103,17 +104,18 @@
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
-CONFIG_NO_HZ_IDLE=y
-# CONFIG_NO_HZ_FULL is not set
+# CONFIG_NO_HZ_IDLE is not set
+CONFIG_NO_HZ_FULL=y
+CONFIG_NO_HZ_FULL_ALL=y
+# CONFIG_NO_HZ_FULL_SYSIDLE is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
-CONFIG_TICK_CPU_ACCOUNTING=y
-# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
-# CONFIG_IRQ_TIME_ACCOUNTING is not set
+CONFIG_VIRT_CPU_ACCOUNTING=y
+CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
@@ -127,17 +129,16 @@
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
-# CONFIG_RCU_USER_QS is not set
+CONFIG_CONTEXT_TRACKING=y
+CONFIG_RCU_USER_QS=y
+# CONFIG_CONTEXT_TRACKING_FORCE is not set
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
-CONFIG_RCU_FAST_NO_HZ=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
CONFIG_RCU_NOCB_CPU=y
-CONFIG_RCU_NOCB_CPU_NONE=y
-# CONFIG_RCU_NOCB_CPU_ZERO is not set
-# CONFIG_RCU_NOCB_CPU_ALL is not set
+CONFIG_RCU_NOCB_CPU_ALL=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=19
@@ -164,7 +165,6 @@
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
-CONFIG_RT_GROUP_SCHED=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CHECKPOINT_RESTORE=y
@@ -197,7 +197,7 @@
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
-# CONFIG_KALLSYMS_ALL is not set
+CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
@@ -222,13 +222,10 @@
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
-# CONFIG_SLAB is not set
CONFIG_SLUB=y
CONFIG_SLUB_CPU_PARTIAL=y
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
-CONFIG_OPROFILE=m
-# CONFIG_OPROFILE_EVENT_MULTIPLEX is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
CONFIG_KPROBES=y
@@ -337,7 +334,6 @@
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_PADATA=y
CONFIG_ASN1=m
-CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_FREEZER=y

#
@@ -395,9 +391,15 @@
CONFIG_NR_CPUS=128
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
+CONFIG_PREEMPT=y
+CONFIG_PREEMPT_RT_BASE=y
+CONFIG_HAVE_PREEMPT_LAZY=y
+CONFIG_PREEMPT_LAZY=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
-CONFIG_PREEMPT=y
+# CONFIG_PREEMPT__LL is not set
+# CONFIG_PREEMPT_RTB is not set
+CONFIG_PREEMPT_RT_FULL=y
CONFIG_PREEMPT_COUNT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
@@ -466,9 +468,6 @@
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
CONFIG_MEMORY_FAILURE=y
CONFIG_HWPOISON_INJECT=m
-CONFIG_TRANSPARENT_HUGEPAGE=y
-CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
-# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_CLEANCACHE=y
CONFIG_FRONTSWAP=y
@@ -493,9 +492,9 @@
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
-CONFIG_HZ_300=y
-# CONFIG_HZ_1000 is not set
-CONFIG_HZ=300
+# CONFIG_HZ_300 is not set
+CONFIG_HZ_1000=y
+CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
@@ -1614,6 +1613,7 @@
# CONFIG_AD525X_DPOT_SPI is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_IBM_ASM is not set
+CONFIG_HWLAT_DETECTOR=m
CONFIG_PHANTOM=m
CONFIG_SGI_IOC4=m
CONFIG_TIFM_CORE=m
@@ -1937,10 +1937,6 @@
CONFIG_MD_RAID456=m
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
-CONFIG_BCACHE=m
-# CONFIG_BCACHE_DEBUG is not set
-# CONFIG_BCACHE_EDEBUG is not set
-# CONFIG_BCACHE_CLOSURES_DEBUG is not set
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_DEBUG is not set
CONFIG_DM_BUFIO=m
@@ -2018,11 +2014,8 @@
CONFIG_MACVLAN=m
CONFIG_MACVTAP=m
CONFIG_VXLAN=m
-CONFIG_NETCONSOLE=m
-CONFIG_NETCONSOLE_DYNAMIC=y
-CONFIG_NETPOLL=y
-# CONFIG_NETPOLL_TRAP is not set
-CONFIG_NET_POLL_CONTROLLER=y
+# CONFIG_NETPOLL is not set
+# CONFIG_NET_POLL_CONTROLLER is not set
CONFIG_RIONET=m
CONFIG_RIONET_TX_SIZE=128
CONFIG_RIONET_RX_SIZE=128
@@ -5825,7 +5818,6 @@
CONFIG_HAVE_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
-# CONFIG_DEBUG_SHIRQ is not set

#
# Debug Lockups and Hangs
@@ -5882,7 +5874,7 @@
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
-# CONFIG_LATENCYTOP is not set
+CONFIG_LATENCYTOP=y
CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS=y
# CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
@@ -5902,7 +5894,6 @@
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
-CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
@@ -5912,6 +5903,8 @@
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_PREEMPT_TRACER is not set
CONFIG_SCHED_TRACER=y
+CONFIG_WAKEUP_LATENCY_HIST=y
+CONFIG_MISSED_TIMER_OFFSETS_HIST=y
CONFIG_FTRACE_SYSCALLS=y
CONFIG_TRACER_SNAPSHOT=y
# CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP is not set
@@ -6197,7 +6190,6 @@
CONFIG_GENERIC_IO=y
CONFIG_PERCPU_RWSEM=y
CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
-CONFIG_CMPXCHG_LOCKREF=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_T10DIF=m
@@ -6272,4 +6264,4 @@
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_10x18 is not set
-CONFIG_FONT_AUTOSELECT=y
\ No newline at end of file
+CONFIG_FONT_AUTOSELECT=y

Det commented on 2014-03-11 20:09

What is that question?

mindhack commented on 2014-03-06 18:57

Is there a list with the configuration differences against the [core] kernel?

Thanks!

Ninez commented on 2014-03-02 23:10

@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

@Ninez, any news on the AMD Phenom II 965 x4 issue?

jhernberg commented on 2014-02-18 19:30

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

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

rt17 out

Ninez commented on 2014-02-12 14:43

@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

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

Ninez commented on 2014-02-11 15:56

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

Ninez commented on 2014-02-11 15:19

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

Ninez commented on 2014-02-11 12:38

@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

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

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

Thanks Ninez! I'll try your l-pa kernel. Looks interesting.

Ninez commented on 2014-02-06 02:08

@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

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

Hmm.. -rt13 is up.

Ninez commented on 2014-02-01 12:35

@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

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

Ninez commented on 2014-02-01 11:59

@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

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

Ninez commented on 2014-01-19 15:26

@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

@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

https://launchpad.net/kxstudio/+announcement/6610 << towards the issue with pulseaudio (solved it for me on linux-l-pa)

jhernberg commented on 2014-01-12 13:32

@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

@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

'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

Ninez commented on 2014-01-04 20:26

@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; http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Daemon/ (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

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?

Ninez commented on 2014-01-04 13:50

@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

pulseaudio stops running occasionally with this kernel for some reason

jhernberg commented on 2013-12-29 11:53

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

"https://www.kernel.org/pub/linux/kernel/projects/rt/${_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

no boot... maybe incompatible patches... I'll wait new pkgbuild

ilkyest commented on 2013-12-28 22:35

no boot... trying compile it again... maybe something wrong during compiling

ilkyest commented on 2013-12-28 17:29

I could try compiling changing md5sums like here
https://www.kernel.org/pub/linux/kernel/projects/rt/3.12/

but, I'm applying this patch now...
https://www.kernel.org/pub/linux/kernel/projects/rt/3.12/patch-3.12.6-rt9.patch.xz

I'm compiling it, and after I post here my results

ilkyest commented on 2013-12-28 17:18

The requested URL /pub/linux/kernel/projects/rt/3.12/patch-3.12.5-rt7.patch.xz was not found on this server.

Ninez commented on 2013-12-18 18:47

@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

@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

@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 kernel.org. Been taken care of now though.

Ninez commented on 2013-12-17 21:33

@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

@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

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-17 12:27

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

@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

@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 :)

student975 commented on 2013-12-11 19:45

I have uploaded last - 1.0 - version to make qloud compatible with last - v.6.1 - qwt.

Ninez commented on 2013-12-06 22:36

@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; http://pastebin.com/4SuApqvn ...

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

@Ninez & @jhernberg: Experiencing the same issues: http://pastebin.com/CW8FtQvb
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! :)

Ninez commented on 2013-12-05 18:36

I started a (fairly detailed) thread at nvidia; https://devtalk.nvidia.com/default/topic/654639/linux/nvidia-using-wbinvdt-lt-an-intel-instruction-gt-causes-huge-latency-spikes-essentially-that-i/ ... It may be like tossing a coin in a wishing well, but that's okay. - maybe it will lead to change :)

Ninez commented on 2013-12-05 16:47

@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

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

Ninez commented on 2013-12-04 03:06

@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; https://aur.archlinux.org/packages/nvidia-l-pa/ ... 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 ...lol - and that was only 2 cores. My average MAX: is around 20-30 now :)

Ninez commented on 2013-12-04 03:05

@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; https://aur.archlinux.org/packages/nvidia-l-pa/ ... 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 ...lol - and that was only 2 cores. My average MAX: is around 20-30 now :)

Ninez commented on 2013-12-03 23:06

@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

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

Ninez commented on 2013-12-02 19:03

@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

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

Ninez commented on 2013-12-02 17:17

@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 > http://www.spinics.net/lists/linux-rt-users/msg07804.html

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

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

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

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.

Ninez commented on 2013-11-25 00:56

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.

Ninez commented on 2013-11-24 23:53

@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

So how's 3.12.1-rt4?

Ninez commented on 2013-11-23 01:37

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

jhernberg commented on 2013-11-22 12:25

@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

@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

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

Ninez commented on 2013-11-22 02:43

@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

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

jhernberg commented on 2013-11-21 23:19

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?

Ninez commented on 2013-11-21 18:37

@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

@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

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

Ninez commented on 2013-11-21 00:43

@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

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

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

Ninez commented on 2013-11-20 21:14

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

Ninez commented on 2013-11-20 21:14

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

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

Ninez commented on 2013-11-20 19:29

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.

Ninez commented on 2013-11-20 19:28

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.10.x-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.

Ninez commented on 2013-11-20 19:12

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

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

Ninez commented on 2013-11-20 18:21

@Jhernberg - try disabling CONFIG_NO_HZ_IDLE feature and see if you still get lockups.

Ninez commented on 2013-11-20 18:21

@Jhernberg - try disabling CONFIG_NO_HZ_IDLE feature and see if you still get lockups.




jhernberg commented on 2013-11-14 16:05

@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

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

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

@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

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:53

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

forkenbrock commented on 2013-09-02 07:43

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

forkenbrock commented on 2013-09-01 15:42

Looks good so far. No problems completing the makepkg after the command to update the checksums.

forkenbrock commented on 2013-09-01 15:28

Looks good so far. No problems completing the makepkg after the command to update the checksums.

forkenbrock commented on 2013-09-01 15:26

Looks good so far. I don't have any problems completing the makepkg now.

jhernberg commented on 2013-08-31 22:41

Ok uploaded, but not tested :)

jhernberg commented on 2013-08-31 22:28

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

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:
"https://www.kernel.org/pub/linux/kernel/projects/rt/${_basekernel}/patch-${_pkgver}-${_rtpatchver}.patch.xz"
for
"https://www.kernel.org/pub/linux/kernel/projects/rt/${_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

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 <jbh@alchemy.lu>
# Contributor: Ray Rashif <schiv@archlinux.org>
# Contributor: timbosa <tinny_tim@dodo.com.au>
# Contributor: Tobias Powalowski <tpowa@archlinux.org>
# Contributor: Thomas Baechler <thomas@archlinux.org>

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="http://rt.wiki.kernel.org/"
license=('GPL2')
makedepends=('xmlto' 'docbook-xsl' 'kmod' 'inetutils' 'bc' 'ncurses')
options=('!strip')
source=("https://www.kernel.org/pub/linux/kernel/v3.x/linux-${_basekernel}.tar.xz"
"https://www.kernel.org/pub/linux/kernel/v3.x/patch-${_pkgver}.xz"
"https://www.kernel.org/pub/linux/kernel/projects/rt/${_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

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?

forkenbrock commented on 2013-08-31 20:35

I seem to get the 404 error on my machine as well.

Morgan_Cox commented on 2013-08-31 10:10

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

@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

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

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

@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

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

@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

@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

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

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

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

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: http://blog.sebjan.net/increase-a-tmpfs-partition-size-on-the-go

jhernberg commented on 2013-08-18 16:16

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

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

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

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: https://wiki.archlinux.org/index.php/Yaourt#Yaourt_freezing_.2F_system_heavy_slowdown 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

yaourt.....it 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

@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

thanks, I comented it out and will try again.

jhernberg commented on 2013-08-18 14:24

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.

jhernberg commented on 2013-08-18 14:23

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

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

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

this build is getting to big for my tmpfs.....any workaround?

boulogne75 commented on 2013-08-16 20:21

Sorry again and thanks.

jhernberg commented on 2013-08-16 20:17

@boulogne75: Don't worry about it, Was far less time consuming than updating the package :)

boulogne75 commented on 2013-08-16 18:58

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.

boulogne75 commented on 2013-08-16 18:53

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

@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

The patch moved to https://www.kernel.org/pub/linux/kernel/projects/rt/3.10/older/ .

jhernberg commented on 2013-08-10 17:42

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

Seems to work fine so far, so have uploaded -rt13

jhernberg commented on 2013-06-28 16:42

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

rt12

smoge commented on 2013-06-14 20:02

3.8.13-rt11

paum commented on 2013-06-14 08:02

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

OK, I've uploaded an archive again.

paum commented on 2013-06-13 09:06

@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

To be more precise, I mean the linux-rt-users@vger.kernel.org mailing list.

jhernberg commented on 2013-06-12 11:30

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

crash: http://pastebin.com/EV19yGyD

arie commented on 2013-06-11 23:59

I get this in dmesg
[ 7.369355] BUG: scheduling while atomic: swapper/3/0/0x00010002
[ 7.369368] Modules linked in: vboxdrv(O+) ext4 crc16 mbcache jbd2 hid_generic usbhid hid sr_mod sd_mod cdrom ahci libahci ehci_pci libata sdhci_pci xhci_hcd ehci_hcd sdhci scsi_mod mmc_core usbcore usb_common i915 video button i2c_algo_bit intel_agp intel_gtt drm_kms_helper drm i2c_core
[ 7.369370] Pid: 0, comm: swapper/3 Tainted: G O 3.8.13-rt10-1-rt #1
[ 7.369371] Call Trace:
[ 7.369379] <IRQ> [<ffffffff814b927f>] __schedule_bug+0x4d/0x59
[ 7.369381] [<ffffffff814bf3ed>] __schedule+0x97d/0x990
[ 7.369384] [<ffffffff8109477c>] ? update_curr+0xcc/0x1e0
[ 7.369387] [<ffffffff810b40e4>] ? task_blocks_on_rt_mutex+0xf4/0x260
[ 7.369388] [<ffffffff814bf429>] schedule+0x29/0x70
[ 7.369390] [<ffffffff814c0051>] rt_spin_lock_slowlock+0x177/0x2a6
[ 7.369393] [<ffffffff8108b401>] ? check_preempt_curr+0x21/0xa0
[ 7.369405] [<ffffffffa032ce30>] ? VBoxHost_RTMpIsCpuWorkPending+0x10/0x10 [vboxdrv]
[ 7.369407] [<ffffffff814c06b5>] rt_spin_lock+0x25/0x30
[ 7.369418] [<ffffffffa032e9d6>] VBoxHost_RTSpinlockAcquire+0x36/0x50 [vboxdrv]
[ 7.369430] [<ffffffffa031fa66>] supdrvGipMpEventOnline+0x66/0x220 [vboxdrv]
[ 7.369440] [<ffffffffa032ce30>] ? VBoxHost_RTMpIsCpuWorkPending+0x10/0x10 [vboxdrv]
[ 7.369449] [<ffffffffa031fc35>] supdrvGipInitOnCpu+0x15/0x20 [vboxdrv]
[ 7.369458] [<ffffffffa032ce58>] rtmpLinuxWrapper+0x28/0x30 [vboxdrv]
[ 7.369460] [<ffffffff810b5651>] generic_smp_call_function_interrupt+0xa1/0x1d0
[ 7.369463] [<ffffffff81386100>] ? show_available_freqs+0xa0/0xa0
[ 7.369466] [<ffffffff810393f7>] smp_call_function_interrupt+0x27/0x40
[ 7.369468] [<ffffffff814c949d>] call_function_interrupt+0x6d/0x80
[ 7.369471] <EOI> [<ffffffff81386d11>] ? cpuidle_wrap_enter+0x41/0x80
[ 7.369473] [<ffffffff81386130>] cpuidle_enter_tk+0x10/0x20
[ 7.369474] [<ffffffff813868d3>] cpuidle_idle_call+0xb3/0x3d0
[ 7.369476] [<ffffffff8101f0af>] cpu_idle+0x10f/0x160
[ 7.369478] [<ffffffff814afa5c>] start_secondary+0x25a/0x25c

arie commented on 2013-06-11 17:45

why i get this ?
BUG: scheduling while atomic: swapper/2/0/0x00010002

jhernberg commented on 2013-05-08 07:41

@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

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

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

@paum: if you mean tarballs for the kernels themselves, they are all on kernel.org. If you mean the old PKGBUILD scripts, these are the ones i still have: https://dl.dropboxusercontent.com/u/879835/linux-rt-src.zip 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

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

Seems like for the devs too: http://thread.gmane.org/gmane.linux.rt.user/9869/focus=9877

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

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

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

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

3.8.4-rt1 is actually already there: https://www.kernel.org/pub/linux/kernel/projects/rt/3.8/

What's this GPL problem you're talking about?

jhernberg commented on 2013-03-23 11:10

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 kernel.org 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

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

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

@jhernberg: nope, not yet. Will do if this version fails, too.

jnbek commented on 2013-02-13 21:41

I wish that the 32 bit OSs would die in a fire already... </rant>

jhernberg commented on 2013-02-13 21:39

Heh, didn't take all that long after all...:)

Enjoy..

jhernberg commented on 2013-02-13 10:08

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

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

jhernberg commented on 2013-02-06 21:02

@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

Okay, "working" with acpi=off now... and breakage (http://pastebin.com/vBpGzpVe). :/
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 :/

dvzrv commented on 2013-01-07 00:29

Hmm, I can't get this one to work with nvidia-rt, using the 304xx.
Dies after early boot sequence and Kernel decompress. No Kernel panic, just freeze and death :/

Det commented on 2012-12-24 03:09

rt25.

jhernberg commented on 2012-12-17 12:22

@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

i can't find the RT patch config inside make menuconfig ?

fivedigits commented on 2012-12-12 10:28

link to patch-3.6.9-rt21.patch.xz is broken,
patch now resides in
http://http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/older/patch-3.6.9-rt21.patch.xz

please update

rickysheaves commented on 2012-12-03 19:34

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:

http://www.kernel.org/pub/linux/kernel/projects/rt/${_basekernel}/patch-${_pkgver}-${_rtpatchver}.patch.xz

To this:

http://www.kernel.org/pub/linux/kernel/projects/rt/${_basekernel}/older/patch-${_pkgver}-${_rtpatchver}.patch.xz

rickysheaves commented on 2012-12-03 19:32

patch-3.6.8-rt19.patch.xz is available, so this is technically out of date at the moment.

Please update PKGBUILD:

_releasever=7 ==> _releasever=8
_rtpatchver=rt18 ==> _rtpatchver=rt19
134936c362d8812b5cafcf3c67afdce0 ==> 134936c362d8812b5cafcf3c67afdce0
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:

http://www.kernel.org/pub/linux/kernel/projects/rt/${_basekernel}/patch-${_pkgver}-${_rtpatchver}.patch.xz

To this:

http://www.kernel.org/pub/linux/kernel/projects/rt/${_basekernel}/older/patch-${_pkgver}-${_rtpatchver}.patch.xz

rickysheaves commented on 2012-12-03 19:17

patch-3.6.8-rt19.patch.xz is available, so this is technically out of date at the moment.

Please update PKGBUILD:
_rtpatchver=rt18 ==> _rtpatchver=rt19
_releasever=7 ==> _releasever=8
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:

http://www.kernel.org/pub/linux/kernel/projects/rt/${_basekernel}/patch-${_pkgver}-${_rtpatchver}.patch.xz

To this:

http://www.kernel.org/pub/linux/kernel/projects/rt/${_basekernel}/older/patch-${_pkgver}-${_rtpatchver}.patch.xz

Anonymous comment on 2012-11-26 15:44

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

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

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

@jhernberg
Thanks for all these useful tips, they make the job easier ;)

jhernberg commented on 2012-11-15 14:24

@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

@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

@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

@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

@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

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

There are several archaudio repos, so add the following to your /etc/pacman.conf:

[archaudio-production]
Server = http://repos.archaudio.org/$repo/$arch

jhernberg commented on 2012-11-09 13:33

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

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.

Anonymous comment on 2012-11-08 08:58

Yes, it's console login.

jhernberg commented on 2012-11-08 07:59

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.

Anonymous comment on 2012-11-08 07:21

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

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:39

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 http://dl.dropbox.com/u/879835/linux-rt-3.6.5_rt15-1.src.tar.gz . 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.

jhernberg commented on 2012-11-04 11:23

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 http://dl.dropbox.com/u/879835/linux-rt-3.6.5_rt15-1.src.tar.gz . 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

3.4.17-rt28. Also the ever so promptly released 3.6.5-rt15 fixes some "embarassing typos" in rt14: http://www.spinics.net/lists/linux-rt-users/msg08787.html

jhernberg commented on 2012-11-02 12:51

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: http://dl.dropbox.com/u/879835/linux-rt-3.6.5_rt14-1.src.tar.gz

jhernberg commented on 2012-10-31 20:43

Here is 3.6.4-rt11 if anyone wants to test it: http://dl.dropbox.com/u/879835/linux-rt-3.6.4_rt11-1.src.tar.gz

jhernberg commented on 2012-10-31 12:56

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

There's rt11 already: http://www.spinics.net/lists/linux-rt-users/msg08770.html

jhernberg commented on 2012-10-30 22:52

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

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 http://dl.dropbox.com/u/879835/linux-rt-3.6.4_rt10-1.src.tar.gz
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.

Ninez commented on 2012-10-29 20:42

@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

3.4.15-rt24/3.6.4-rt10

@Ninez, you realize what NUMA is?

Det commented on 2012-10-29 17:48

3.4.15-rt24/3.6.4-rt10

Ninez commented on 2012-10-27 23:34

@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

@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: https://lwn.net/Articles/521022/

Ninez commented on 2012-10-24 12:58

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

Ninez commented on 2012-10-24 00:12

@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

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

@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

3.4.14-rt23 and 3.6.2-rt4

smoge commented on 2012-10-20 18:39

Hey, jhernberg, what was the problem you referred to in your comment from 21 Sep 2012?

smoge commented on 2012-10-20 18:37

3.4.14-rt23

smoge commented on 2012-10-16 19:02

https://lkml.org/lkml/2012/10/16/428

Det commented on 2012-10-15 21:27

Related to this perhaps?: http://www.spinics.net/lists/linux-rt-users/msg08575.html

Unflagging, since breaking other people's systems isn't really grounds for a new release.

jhernberg commented on 2012-10-15 16:11

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

No it was a joke you see.

3.6.2's been pulled to [core]: https://www.archlinux.org/packages/core/x86_64/linux/

jhernberg commented on 2012-10-11 21:34

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

No need to attack me. I was just being informative.

jhernberg commented on 2012-10-09 19:53

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

3.4.12-rt20 and 3.6.1-rt1 are up.

jhernberg commented on 2012-09-21 17:50

Think I got it all working again. Please let me know if there are any problems..

jhernberg commented on 2012-09-16 20:46

@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 :(

jhernberg commented on 2012-09-16 20:38

Indeed the devs have broken things again :( Let me see if I can fix the package build yet again..

dgbaley27 commented on 2012-09-16 20:01

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

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

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

@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

First,

Has any work been done to optimize .config for CONFIG_PREEMPT_RT? I read on rt.wiki.kernel.org 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.

Ninez commented on 2012-07-17 13:48

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

I have updated the script, think the problem was due to http://www.archlinux.org/news/the-lib-directory-becomes-a-symlink/

Ninez commented on 2012-07-17 00:44

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/99.98.3.4.4-rt13-1-rt: 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?

Ninez commented on 2012-07-17 00:33

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/99.98.3.4.4-rt13-1-rt: 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

@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: http://rg42.org/oss/jackfreqd/start

also there are other uses for this kernel than audio. so, disconsider my question.


Greets

jhernberg commented on 2012-07-12 12:32

@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

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

Thanks smoge, i didn't see that one..

smoge commented on 2012-06-19 05:29

jhernberg, you may change `module-init-tools>=3.16'' to ``kmod''

smoge commented on 2012-06-19 03:29

hey jhernberg, you may change `module-init-tools>=3.16'' for ``kmod''

jhernberg commented on 2012-06-18 17:03

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

@jhernberg: I'll continue with linux 3.0, following the changes in Arch linux-lts.

jhernberg commented on 2012-06-13 08:23

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.

Anonymous comment on 2012-06-11 15:01

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

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

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

btw. thanks to jhernberg for revitalizing audio repros

capoeira commented on 2012-06-08 14:12

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

@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

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

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

Why don't you upload here the latest version?

smoge commented on 2012-06-07 17:18

3.2-rt31 and 3.4.1-rt9

smoge commented on 2012-06-07 04:52

rt30

jhernberg commented on 2012-06-05 12:33

i've uploaded 3.4.0-rt8 to [archaudio-preview]

smoge commented on 2012-06-04 22:30

3.4.rt8 is out

jhernberg commented on 2012-06-02 14:52

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: http://archaudio.org/packages/ 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

@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

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

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

3.4-rt7 is out

jhernberg commented on 2012-05-16 08:40

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

Would be a good idea to merge changes from `linux`:

https://projects.archlinux.org/svntogit/packages.git/log/trunk?h=packages/linux

smoge commented on 2012-05-03 20:24

@jhernberg the only problem with nouveau is the higher temperature, which make more fan noise (bad for audio, of course). It's a NVIDIA Quadro FX 880M.

smoge commented on 2012-05-03 20:22

@jhernberg I use nvidia with nouveau driver, linux-rt-lts is very stable using nouveau here.

Ninez commented on 2012-05-03 17:42

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

Yeah, I've been looking at diffs and am planning a few changes for 3.4.
@ smoge, do you also use a nvidia card?

smoge commented on 2012-05-03 01:24

@jhernberg maybe this can help to find out. Those are the diff between:
linux-rt-lts and linux-rt: http://hpaste.org/67986
linux and linux-rt: http://hpaste.org/67987

jhernberg commented on 2012-04-22 18:16

@felixonmars Have you tried with nouveau for instance?

felixonmars commented on 2012-04-20 16:34

@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

@felixonmars. Does it work with another video driver?

felixonmars commented on 2012-04-19 15:18

@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

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

@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

Unfortunately I'm still getting system freezes with this one, not with linux and linux-rt-lts.

Anonymous comment on 2012-04-04 09:34

@jhernberg Fixed thanks.

jhernberg commented on 2012-04-04 09:13

@parchedtoads
They moved the older -rt patches on kernel.org so when a new patch comes out the package is broken until updated.

Try again now.

Anonymous comment on 2012-04-04 07:44

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

Anonymous comment on 2012-03-23 19:12

rt21 is outdated, now rt22

jhernberg commented on 2012-03-17 11:43

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

Very good job, thanks for maintaining it

capoeira commented on 2012-02-09 15:43

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

@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

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

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

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

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

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

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

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

patches-3.2.5-rt11.tar.xz

capoeira commented on 2012-02-06 22:45

many, many thanks for the update

jhernberg commented on 2012-02-05 21:35

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

smoge commented on 2012-02-05 21:29

What I mean is this patch was created before 3.2.4 existed, so it is less safe to use it if you're not familiar with the internals of the code to check it out. But if it works well and it's good, great.

smoge commented on 2012-02-05 21:28

What I mean is this patch was created before 3.2.4 existed, but it is less safe if you're not familiar with the internals of the code to check it out.

jhernberg commented on 2012-02-05 21:19

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.

jhernberg commented on 2012-02-05 21:12

Hehe, you guys need to wake up and have a look at kernel.org :)

smoge commented on 2012-02-05 21:09

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

Nice! You're way ahead of the game, jhernberg. I'm awake and enlightened now.

jhernberg commented on 2012-02-05 20:58

Hehe, you guys need to wake up and have a look at kernel.org :)

WiZeTeK commented on 2012-02-05 19:12

Switch back '_releasever=4' to '_releasever=2' and change 'pkgrel=1' to 'pkgrel=2'.

smoge commented on 2012-02-05 19:01

Something strange: it should be 3.2.2-rt10, not 3.2.4-rt10.

jhernberg commented on 2012-02-05 14:21

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

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

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:
https://aur.archlinux.org/packages/li/linux-pae/PKGBUILD

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:06

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

jhernberg commented on 2012-02-04 23:01

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

I think I would show just `Linux 3.2.2-1-rt`?

jhernberg commented on 2012-01-29 17:41

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.

smoge commented on 2012-01-29 10:59

https://aur.archlinux.org/packages.php?ID=56195

jhernberg commented on 2012-01-29 03:05

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.

smoge commented on 2012-01-28 05:20

3.0.18-rt34

schivmeister commented on 2012-01-27 09:50

Have not been doing justice to this kernel for a long time now..so passing it on to someone else. Orphaning for jhernberg..

capoeira commented on 2012-01-23 19:02

will this be updated to 3.2?

smoge commented on 2012-01-21 04:57

3.0.17-rt33. Maybe this package should be linux-rt-lts?

http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz
http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.17.xz
http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.17-rt33.patch.xz

hermes14 commented on 2012-01-20 22:04

3.2-rt10

http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patches-3.2-rt10.tar.xz

smoge commented on 2012-01-20 19:00

3.0.14-rt32

http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz
http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.14.xz
http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.14-rt32.patch.xz

smoge commented on 2012-01-13 18:43

Well, I don't know how stable 3.2-rt10 is already, and if 3.0-rt will be a `LTS' or not. In that case a linux-rt-lts would make sense too.

smoge commented on 2012-01-13 05:01

3.2-rt10 is out.

Morgan_Cox commented on 2012-01-12 23:31

Hi

Just to let you know I have updated the nvidia-rt package now.

https://aur.archlinux.org/packages.php?ID=12132

It should work regardless of how you have compiled the kernel now.

Anonymous comment on 2012-01-04 20:34

I unflagged this package as being out of date. rt31 is still the latest real-time patchset available.

Best,

Jeremy

Anonymous comment on 2011-12-27 21:30

Anybody else experiencing kernel crashes with VST plugins like the ones from TAL?

Best,

Jeremy

Anonymous comment on 2011-12-27 20:42

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

smoge commented on 2011-12-08 03:42

@felixonmars: that would be another package like ``linux-rt-unstable''

smoge commented on 2011-12-07 23:56

http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz
http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.12.xz
http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.12-rt30.patch.xz

schivmeister commented on 2011-12-06 05:54

When it comes out of RC and becomes stable :)

felixonmars commented on 2011-12-06 04:25

Since 3.2-rc4-rt6 RT already released, I'd like to ask when will this package go 3.2-series? Thanks.

smoge commented on 2011-12-02 18:20

http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patches-3.0.12-rt29.tar.xz

smoge commented on 2011-12-02 17:41

http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz
http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.12.xz
http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.12-rt29.patch.xz

schivmeister commented on 2011-11-28 08:50

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

What about the tickless kernel feature (CONFIG_NO_HZ option)?

Anonymous comment on 2011-11-24 16:29

please edit PKGBUILD and include "older/" in the following path:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/

so it will looks like:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/older/

Thanks

smoge commented on 2011-11-22 18:59

3.0.9-rt26 is out!
http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz
http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.9.xz
http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.9-rt26.patch.xz

smoge commented on 2011-11-22 18:58

3.0.9-rt26 is out

Anonymous comment on 2011-11-16 15:59

3.0.9 with rt25 - http://pastebin.com/WvxWUnGV
If you get an error downloading rt25 from https://tglx.de/~tglx/rt/3.0/ 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

"The 3.0 RT series has reached the production stability point."

smoge commented on 2011-11-12 18:49

3.0.9-rt25 is out

feilen commented on 2011-11-11 04:02

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

http://pastebin.com/5cfPEQib Theoretically fixed PKGBUILD, look for anything obvious that I forgot to change

smoge commented on 2011-11-09 23:55

Maybe it will be a bit less safe since nobody is testing or supporting it? Nouveau is doing pretty good here.

jeremydei commented on 2011-11-09 04:46

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

smoge commented on 2011-11-08 23:19

3.0.8-rt23 is out!

smoge commented on 2011-11-07 21:39

3.0.8-rt22 is out!

Morgan_Cox commented on 2011-10-26 09:57

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

Yes, thanks. I'll take a look at why this PKGBUILD reverts all those perms (that are done appropriately in the package function).

Ninez commented on 2011-10-23 14:38

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

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

3.0.7-rt20 is out

smoge commented on 2011-10-19 23:39

3.0.7-rt020 is out

schivmeister commented on 2011-10-15 15:27

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

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

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

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

Changed the archlinux.org from http to ftp.

schivmeister commented on 2011-10-15 10:21

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

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

Something happened. I can't access ftp.archlinux.org either :/

capoeira commented on 2011-10-14 21:58

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

Updated. Generic binaries: http://pkgbuild.com/~schiv/linux-rt/

I added in relevant parts for the patching of the kernel for nvidia. Uncomment them if you want to build against nvidia.

Ninez commented on 2011-10-13 22:42

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

http://old.nabble.com/Re%3A-rt-audio-with-kernel-3.0---looking-good-p32231114.html

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

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.

Ninez commented on 2011-10-13 12:24

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

Fixed, thanks.

capoeira commented on 2011-10-08 22:55

there is a typo in the sourcesline: "ftp,archlinux"

schivmeister commented on 2011-10-08 19:30

Updated. Generic binaries at http://pkgbuild.com/~schiv/linux-rt/

smoge commented on 2011-10-07 20:00

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.

smoge commented on 2011-10-07 19:54

rt17 seems pretty good, they seem to fixed the problem I had before.
I'm running it without problems so far.
Jack with 64 frames/period and 5ms latency, no problems, working great.

smoge commented on 2011-10-07 00:59

great. rt17 is out, I'm trying to build it now.

schivmeister commented on 2011-10-06 21:32

Updated. Binaries at the usual place.

smoge commented on 2011-10-04 20:24

3.0.6-rt16 out!

schivmeister commented on 2011-09-28 09:35

Oops, sorry about that. Fixed.

Binaries tentatively at http://pkgbuild.com/~schiv/linux-rt/

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

config fails md5sum

tritonas00 commented on 2011-09-21 09:40

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 ?

smoge commented on 2011-09-21 00:22

also http://mirror.yandex.ru/kernel.org/linux/kernel/v3.0/linux-3.0.4.tar.bz2

tritonas00 commented on 2011-09-20 04:37

Working server : http://193.166.3.2/pub/Linux/kernel/

smoge commented on 2011-09-17 01:26

Also this one: git://tesla.tglx.de/git/linux-2.6-tip rt/3.0

smoge commented on 2011-09-17 01:24

Yes, there is a mirror here: https://github.com/torvalds/linux
The patch is working: https://tglx.de/~tglx/rt/patch-3.0.4-rt14.gz

schivmeister commented on 2011-09-15 15:28

kernel.org is still down. Any place else where we could get the kernel sources?

smoge commented on 2011-09-14 23:44

3.0.4-rt14 is out: https://lkml.org/lkml/2011/9/14/297

smoge commented on 2011-09-10 16:24

Since the kernel.org seems not to work right now, one can get the sources here (from the announce email)

Patch against 3.0.4 can be found here:

https://tglx.de/~tglx/rt/patch-3.0.4-rt13.patch.gz

The split quilt queue is available at:

https://tglx.de/~tglx/rt/patches-3.0.4-rt13.tar.gz

For those who don't have 3.0.4 around:

git://tesla.tglx.de/git/linux-2.6-tip rt/3.0

https://tglx.de/~tglx/rt/patch-3.0.4.gz

smoge commented on 2011-09-10 16:22

3.0.4-rt13 is out

schivmeister commented on 2011-09-03 09:51

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?

smoge commented on 2011-09-03 05:30

3.0.3-rt12 is out =)

funkmuscle commented on 2011-08-21 00:50

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

Anyone with nvidia-driver tried that "sed"line?

schivmeister commented on 2011-08-19 09:33

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

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

Use stock kernel, or -ck, or just -bfs :)

schivmeister commented on 2011-08-18 12:11

Use stock kernel :)

funkmuscle commented on 2011-08-17 21:28

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

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?

Anonymous comment on 2011-08-14 13:42

good.

capoeira commented on 2011-08-14 13:17

Group scheduling for SCHED_RR/FIFO (RT_GROUP_SCHED) [N/y/?] (NEW)

smoge commented on 2011-08-14 11:35

I think it's rt11 already.

schivmeister commented on 2011-08-13 17:58

@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

I mean make localmodconfig. I'll moving this week, little time for testings.

smoge commented on 2011-08-13 12:58

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

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 https://bbs.archlinux.org/viewtopic.php?id=124425 and http://www.nvnews.net/vbulletin/showthread.php?t=165238 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

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

schivmeister commented on 2011-08-12 07:01

@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)?

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.

Anonymous comment on 2011-08-12 01:35

nvidia and browadcom-wl not work

smoge commented on 2011-08-12 00:02

But with the same issue..

smoge commented on 2011-08-11 22:07

linux-rt9 is out

smoge commented on 2011-08-11 18:23

schivmesiter: no, it did not help much..

schivmeister commented on 2011-08-11 05:58

@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

Compiles and runs here (x86_64 icore7). But performance is really bad, very slow/unresponsive desktop.

smoge commented on 2011-08-11 03:21

COmpiles and run here (x86_64 icore7). But the performance is really bad, very slow/unresponsive desktop.

akurei commented on 2011-08-10 16:21

Works perfect so far =) Thanks a lot!

schivmeister commented on 2011-08-10 14:24

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

my problem is gone, i reseted BIOS, só I guess it is related.

Ninez commented on 2011-08-10 02:51

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

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

Building this now. Having great expectations!

schivmeister commented on 2011-08-09 20:20

http://aur.archlinux.org/packages.php?ID=51360 :)

I'll keep this package here for now.

schivmeister commented on 2011-08-09 20:15

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 (http://bugs.archaudio.org/task/5)

Two modules had to be taken out as well: http://www.gossamer-threads.com/lists/linux/kernel/1414935#1414935

Please test.

Binary packages for both architectures available at http://pkgbuild.com/~schiv/linux-rt/ for the meantime.

Anonymous comment on 2011-08-04 22:17

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

thanks for the info shiv

schivmeister commented on 2011-08-04 21:54

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

any news for linux-rt? linux-rt-ice unfortunatly doesn't compile

ngoonee commented on 2011-08-02 08:04

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

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

I will post the new link of linux-rt on nix.uz and we try to collect more votes)

Anonymous comment on 2011-07-24 17:41

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

Anonymous comment on 2011-07-24 16:39

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

Would be nice to keep all those +100 votes for inclusion in community.

KriK commented on 2011-07-24 11:36

I think "linux-rt" is better name

schivmeister commented on 2011-07-23 08:54

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

Hi Ray, the Linux 3.0-rt1 was released today! =) http://lkml.org/lkml/2011/7/22/288

smoge commented on 2011-07-23 01:57

patch: http://www.kernel.org/pub/linux/kernel/projects/rt/patch-3.0-rt1.patch.bz2

smoge commented on 2011-07-23 01:55

Hi Ray, the Linux 3.0-rt1 was released today! =)

mar77i commented on 2011-07-08 11:04

@funkmuscle yes I was able to make it to work with the proprietary nvidia driver.

hermes14 commented on 2011-06-27 10:33

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

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

current 2.6.33.9_rt31-1 doesn't compile here due to https://bugzilla.kernel.org/show_bug.cgi?id=29432

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 https://bugzilla.kernel.org/show_bug.cgi?id=29432
+ 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

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

I have uploaded a PKGBUILD for 2.6.33.9_rt31

This is needed for latest nvidia-rt package.

http://pastebin.com/2CMVAztt

The URL for the kernel patch (2.6.33.9) has changed (see PKGBUILD)

Morgan_Cox commented on 2011-04-11 21:20

Here is an updated PKGBUILD - needed for nvidia-rt:-
---------------------------------------------------


# Maintainer: Ray Rashif <schiv@archlinux.org>
# Contributor: timbosa <tinny_tim@dodo.com.au>
# Contributor: Tobias Powalowski <tpowa@archlinux.org>
# Contributor: Thomas Baechler <thomas@archlinux.org>

pkgname=kernel26rt
_kernelname=${pkgname#kernel26}
_basekernel=2.6.33
_realkernel=2.6.33 # for rc builds, else same as _basekernel
_kernelpatch=.9 # leave blank if no upstream patch
_rtpatch=-rt31
pkgver=2.6.33.9_rt31
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=

# -- nothing to change below this line -- #

pkgdesc="The Linux Kernel and modules - with realtime preemption"
arch=('i686' 'x86_64')
license=('GPL2')
url="http://rt.wiki.kernel.org"
backup=(etc/mkinitcpio.d/$pkgname.preset)
depends=('coreutils' 'linux-firmware' 'module-init-tools' 'mkinitcpio')
optdepends=('crda: to set the correct wireless channels of your country')
provides=('kernel26rt-headers')
install=$pkgname.install
changelog=$pkgname.changelog

[ "$_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="ftp://ftp.kernel.org/pub/linux/kernel/v2.6/${_rc}patch-$_realkernel$_kernelpatch.bz2"
[ -n "$_kernelpatch" ] && _kernpatchurl="http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v$_basekernel/${_rc}patch-$_realkernel$_kernelpatch.bz2"

options=(!strip)
source=(ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-$_realkernel.tar.bz2
$_kernpatchurl
ftp://ftp.kernel.org/pub/linux/kernel/projects/rt/${_rt}patch-$_realkernel$_kernelpatch$_rtpatch.bz2
config
config.x86_64
$pkgname.preset
logo_linux_clut224.ppm
aufs2-base.patch
aufs2-standalone.patch)

build() {
cd "$srcdir/linux-$_realkernel"

# Add upstream patch
if [ -n "$_kernelpatch" ]; then
patch -Np1 -i ../patch-$_realkernel$_kernelpatch
fi

# Add support for AUFS2
patch -Np1 -i ../aufs2-base.patch
patch -Np1 -i ../aufs2-standalone.patch

# Add realtime patch
patch -Np1 -i ../patch-$_realkernel$_kernelpatch$_rtpatch

# Add our custom logo
cp ../logo_linux_clut224.ppm drivers/video/logo/

# Set up configuration
if [ "$CARCH" = "x86_64" ]; then
cat ../config.x86_64 > ./.config
else
cat ../config > ./.config
fi

if [ -f "$startdir/config.save" ]; then
msg "Using previously autosaved config"
cat "$startdir/config.save" > ./.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/config.save"
#make xconfig
#make gconfig
#make oldconfig

# build!
make bzImage modules
}

package() {
cd "$srcdir/linux-$_realkernel"

KARCH=x86
_kernver=$_basekernel-$_kernelname

mkdir -p "$pkgdir"/{lib/modules,boot}
make INSTALL_MOD_PATH="$pkgdir" modules_install
cp System.map "$pkgdir/boot/System.map26$_kernelname"
cp arch/$KARCH/boot/bzImage "$pkgdir/boot/vmlinuz26$_kernelname"

# add vmlinux
install -m644 -D vmlinux "$pkgdir/usr/src/linux-$_kernver/vmlinux"

# install fallback mkinitcpio.conf file and preset file for kernel
install -m644 -D "$srcdir/$pkgname.preset" "$pkgdir/etc/mkinitcpio.d/$pkgname.preset"

# 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'" > "$pkgdir/etc/mkinitcpio.d/$pkgname.kver"

# remove build and source links
rm -f "$pkgdir"/lib/modules/$_kernver/{source,build}

# remove the firmware
rm -rf "$pkgdir/lib/firmware"

# -- package the headers --#

mkdir -p "$pkgdir/lib/modules/$_kernver"
cd "$pkgdir/lib/modules/$_kernver"
ln -sf ../../../usr/src/linux-$_kernver build
cd "$srcdir/linux-$_realkernel"
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 config generated linux math-emu media net pcmcia scsi sound trace 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 -D -m644 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:
# http://bugs.archlinux.org/task/9912
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:
# http://bugs.archlinux.org/task/11194
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 http://mcentral.de/hg/~mrec/em28xx-new
# in reference to:
# http://bugs.archlinux.org/task/13146
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 vor virtualbox
# in reference to:
# http://bugs.archlinux.org/task/14568
cp -a include/drm "$pkgdir/usr/src/linux-$_kernver/include/"

# add headers for broadcom wl
# in reference to:
# http://bugs.archlinux.org/task/14568
cp -a include/trace "$pkgdir/usr/src/linux-$_kernver/include/"

# 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

chown -R root.root "$pkgdir/usr/src/linux-$_kernver"
find "$pkgdir/usr/src/linux-$_kernver" -type d -exec chmod 755 {} \;

# remove unneeded architectures
rm -rf "$pkgdir/usr/src/linux-$_kernver/arch/{alpha,arm,arm26,avr32,blackfin,cris,frv,h8300,ia64,m32r,m68k,m68knommu,mips,microblaze,mn10300,parisc,powerpc,ppc,s390,sh,sh64,sparc,sparc64,um,v850,xtensa}"
}

# vim:set ts=2 sw=2 et:
md5sums=('c3883760b18d50e8d78819c54d579b00'
'f6801744832f9cc7c7993fa2265e86c3'
'110380e5eeb2fbc019c7232037dc522c'
'18da80ac1d41cba0f74cace471862bba'
'bcfba8783fd7d0db1261de2f002ad717'
'a0921a7e563e7ae2d14c3a0603fa16ad'
'6a5a1925501fe20fafd04fdb3cb4f6ed'
'edb62063ec2a61fc82cc00b89920f729'
'e924c5a340f2731c245e6bff8002be13')

smoge commented on 2011-04-11 16:08

new release: http://www.kernel.org/pub/linux/kernel/projects/rt/

schivmeister commented on 2011-03-07 19:18

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

http://marc.info/?l=linux-rt-users&m=129927746730587&w=2

Det commented on 2011-02-21 11:10

As long as you didn't change 'CONFIG_PREEMPT_RT=y' while at it.

Nareto commented on 2011-02-21 11:01

hello, noob question: if I simply exit in menuconfig without changing any options, will I get a real time capable kernel? (needed for audio)

Anonymous comment on 2011-02-01 16:53

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

Anybody got a clue why are they staying with .33? Didn't really find anything by checking the website.

E: Nevermind found this: https://www.osadl.org/Single-View.111+M528d085a4d0.0.html - 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."

Det commented on 2011-01-08 15:42

Anybody got a clue why are they staying with .33? Didn't really find anything by checking the website.

smoge commented on 2010-12-26 17:25

Thanks!!!

smoge commented on 2010-12-25 23:18

Please, update to rt30 or disown.

schivmeister commented on 2010-12-21 17:42

Wow great..still 33. Will update soon.

smoge commented on 2010-12-21 15:07

There is rt30 out. It will be another package or an update of this one?

Morgan_Cox commented on 2010-08-28 18:06

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 2.6.33.7_rt29-1)

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)

http://aur.archlinux.org/packages.php?ID=12132

Morgan_Cox commented on 2010-08-28 12:00

Just in case people are having Nvidia issues (you need a patch to get latest realtime kernel and latest nvidia driver to work)

I have uploaded a package here

http://aur.archlinux.org/packages.php?ID=40328

Anonymous comment on 2010-08-16 08:09

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

# Maintainer: Ray Rashif <schivmeister@gmail.com>
# Contributor: timbosa <tinny_tim@dodo.com.au>
# Contributor: Tobias Powalowski <tpowa@archlinux.org>
# Contributor: Thomas Baechler <thomas@archlinux.org>

pkgname=kernel26rt
_kernelname=${pkgname#kernel26}
_basekernel=2.6.31
_realkernel=2.6.31 # actual basekernel eg. for rc builds
_kernelpatch=.12
_rtpatch=-rt21
pkgver=2.6.31.12_rt21
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="http://rt.wiki.kernel.org"
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="ftp://ftp.kernel.org/pub/linux/kernel/v2.6/${_rc}patch-$_realkernel$_kernelpatch.bz2"

source=(ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-$_realkernel.tar.bz2
$_kernpatchurl
ftp://ftp.kernel.org/pub/linux/kernel/projects/rt/${_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 ../../config.save ]; then
msg "Using previously autosaved config"
cat ../../config.save > ./.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/config.save
#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 System.map "$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:
# http://bugs.archlinux.org/task/9912
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:
# http://bugs.archlinux.org/task/11194
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 http://mcentral.de/hg/~mrec/em28xx-new
# in reference to:
# http://bugs.archlinux.org/task/13146
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:
# http://bugs.archlinux.org/task/14568
cp -a include/drm "$pkgdir/usr/src/linux-$_kernver/include/"
# add headers for broadcom wl
# in reference to:
# http://bugs.archlinux.org/task/14568
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')

ying commented on 2010-04-22 17:27

Broken. This will work with pkgver=2.6.31.12_rt21:


<quote># Maintainer: Ray Rashif <schivmeister@gmail.com>
# Contributor: timbosa <tinny_tim@dodo.com.au>
# Contributor: Tobias Powalowski <tpowa@archlinux.org>
# Contributor: Thomas Baechler <thomas@archlinux.org>

pkgname=kernel26rt
_kernelname=${pkgname#kernel26}
_basekernel=2.6.31
_realkernel=2.6.31 # actual basekernel eg. for rc builds
_kernelpatch=.12
_rtpatch=-rt21
pkgver=2.6.31.12_rt21
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="http://rt.wiki.kernel.org"
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="ftp://ftp.kernel.org/pub/linux/kernel/v2.6/${_rc}patch-$_realkernel$_kernelpatch.bz2"

source=(ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-$_realkernel.tar.bz2
$_kernpatchurl
ftp://ftp.kernel.org/pub/linux/kernel/projects/rt/${_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 ../../config.save ]; then
msg "Using previously autosaved config"
cat ../../config.save > ./.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/config.save
#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 System.map "$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:
# http://bugs.archlinux.org/task/9912
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:
# http://bugs.archlinux.org/task/11194
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 http://mcentral.de/hg/~mrec/em28xx-new
# in reference to:
# http://bugs.archlinux.org/task/13146
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:
# http://bugs.archlinux.org/task/14568
cp -a include/drm "$pkgdir/usr/src/linux-$_kernver/include/"
# add headers for broadcom wl
# in reference to:
# http://bugs.archlinux.org/task/14568
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')</quote>

ying commented on 2010-04-22 17:27

Broken. This will work with pkgver=2.6.31.12_rt21:


<quote># Maintainer: Ray Rashif <schivmeister@gmail.com>
# Contributor: timbosa <tinny_tim@dodo.com.au>
# Contributor: Tobias Powalowski <tpowa@archlinux.org>
# Contributor: Thomas Baechler <thomas@archlinux.org>

pkgname=kernel26rt
_kernelname=${pkgname#kernel26}
_basekernel=2.6.31
_realkernel=2.6.31 # actual basekernel eg. for rc builds
_kernelpatch=.12
_rtpatch=-rt21
pkgver=2.6.31.12_rt21
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="http://rt.wiki.kernel.org"
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="ftp://ftp.kernel.org/pub/linux/kernel/v2.6/${_rc}patch-$_realkernel$_kernelpatch.bz2"

source=(ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-$_realkernel.tar.bz2
$_kernpatchurl
ftp://ftp.kernel.org/pub/linux/kernel/projects/rt/${_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 ../../config.save ]; then
msg "Using previously autosaved config"
cat ../../config.save > ./.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/config.save
#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 System.map "$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:
# http://bugs.archlinux.org/task/9912
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:
# http://bugs.archlinux.org/task/11194
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 http://mcentral.de/hg/~mrec/em28xx-new
# in reference to:
# http://bugs.archlinux.org/task/13146
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:
# http://bugs.archlinux.org/task/14568
cp -a include/drm "$pkgdir/usr/src/linux-$_kernver/include/"
# add headers for broadcom wl
# in reference to:
# http://bugs.archlinux.org/task/14568
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')</quote>

ying commented on 2010-04-22 17:27

Broken. This will work with pkgver=2.6.31.12_rt21:


<quote># Maintainer: Ray Rashif <schivmeister@gmail.com>
# Contributor: timbosa <tinny_tim@dodo.com.au>
# Contributor: Tobias Powalowski <tpowa@archlinux.org>
# Contributor: Thomas Baechler <thomas@archlinux.org>

pkgname=kernel26rt
_kernelname=${pkgname#kernel26}
_basekernel=2.6.31
_realkernel=2.6.31 # actual basekernel eg. for rc builds
_kernelpatch=.12
_rtpatch=-rt21
pkgver=2.6.31.12_rt21
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="http://rt.wiki.kernel.org"
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="ftp://ftp.kernel.org/pub/linux/kernel/v2.6/${_rc}patch-$_realkernel$_kernelpatch.bz2"

source=(ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-$_realkernel.tar.bz2
$_kernpatchurl
ftp://ftp.kernel.org/pub/linux/kernel/projects/rt/${_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 ../../config.save ]; then
msg "Using previously autosaved config"
cat ../../config.save > ./.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/config.save
#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 System.map "$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:
# http://bugs.archlinux.org/task/9912
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:
# http://bugs.archlinux.org/task/11194
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 http://mcentral.de/hg/~mrec/em28xx-new
# in reference to:
# http://bugs.archlinux.org/task/13146
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:
# http://bugs.archlinux.org/task/14568
cp -a include/drm "$pkgdir/usr/src/linux-$_kernver/include/"
# add headers for broadcom wl
# in reference to:
# http://bugs.archlinux.org/task/14568
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')</quote>