I don't actually have a reason for trying to build a Linux kernel with the CONFIG_PREEMPT_RT patch set. There's no way I can even measure the impact of it. Still, I felt like having a "real-time" Linux box, and set out to make one. Little did I know how difficult it would be to even get started.
Post a Comment
Member since:
2008-10-26
The Linux kernel build process can definitely be a bit intimidating at first.
I am not sure why you needed the "O=/path/to/build_dir" option. I've never run across that before; maybe something different in your setup compared to the Debian systems I have built kernels on. Also, after the kernel is built, running make install, make modules_install, and update-grub should handle putting it into the /boot directory and adding it to the grub menu (not sure if update-grub is a Debian-specific tool). You shouldn't have to know about the filenames of everything. As the previous kernel should still be in your grub menu, there isn't much to worry about on whether it works or not: if not, just boot the old kernel and try again.
The kernel you compiled is huge and took a very long time to compile. I suspect this is because you used the Arch default config which (like any distro's configuration) has every driver you could ever possibly want. Kernel builds usually take a few minutes for me (on a Core 2, so it should be faster on your Core i7), but that's with only the drivers I actually use enabled (I vaguely remember some make option for detecting your hardware, but I don't know what it was or if it works well). Also, on a modern multicore, don't forget the -jn option to make where n is the number of processes to run in parallel. The recommendation I usually see is to use number of cores + 1, but I don't know what the actual best value is.
Member since:2007-03-13
I too noticed the far too long amount of build time. You're probably right about the modules, and I guess Vbox does not help here. It took my little core2duo (throttled 1.2-1.6G) 20 minutes.
With a core i7 machine I would go LFS just to see if GCC test suite can run under 20 minutes.
I didn't know about `make all` being coupled to LILO, always good to know.
Member since:2009-03-01
Member since:2008-10-26
Ah, found it. It's called make localmodconfig: http://kernelnewbies.org/Linux_2_6_32#head-11f54cdac41ad6150ef817fd...
Member since:2006-01-24
Yes, the first thing that struck me was 4 hours? On a core i7? Then I saw he wrote 'make', rather than 'make -j5'. Using only one core out of 4 is quite inefficient.
Member since:2006-05-20
The "O=/path/to/build_dir" option just puts the output somewhere else. This isn't especially useful, but it made me feel better. I hate having all the source and binaries jumbled up.
Interesting to know about the compile time. It was longer than I expected, but not a LOT longer. I'll have to see what I can do to trim it down.
Note that I was in a virtual machine. My experience has been the a VM has virtually no impact on purely processor-intensive tasks, but I only gave the VM 1 processor, which is why I didn't use the -jn option.
Member since:
2009-03-01
If you want to do serious audio work in Linux, you would need a rt-capable kernel to run Jackd reliable. It is required by Ardour, Linux-sampler, Hydrogen (the list goes on).
I used to muck about with custom kernels, but now i just use av-linux which comes with everything you need for a Linux based studio. If you are both a musician and a Linux-user, you really should check out Ardour, it's a full featured DAW that can be compared to anything other platforms have to offer, except maybe a lack of bling.
RE: Jackd, that's why!
Member since:2009-03-01
That statement is just silly. Have you actually used the software I just mentioned. I usually do a lot of live audio processing with very cpu intensive plugins like impulse response. On other platforms, the norm seems to be to record with a raw monitor signal, and apply effects afterwards because the system can't handle doing this without using large buffers.
Member since:2007-03-26
I might have a play with building an FX unit using a Linux box this weekend.
I have low latency pro-audio sound card already - just wasn't sure what software to install. What would you recommend for listening to line in and applying real time effects too? (last time I did this, I just did it in Ableton Live on XP - but there was around 32ms latency which made the thing impractical)
Member since:2006-05-30
Rubbish. Try using Reaper under Mac/Windows. It can even run in Linux with WINE. I record live with FX on all the time. I also record ambient room with mic (so no FX required.) Truth is, latency is your enemy, so you need the right drivers for it to work with Windows (ASIO, though ASIO4ALL will work with standard cards), but Mac handles it fine with base system drivers. Even GarageBand will record live audio with FX. But honestly, you really need a real audio card. I use a Tascam 122mk2 personally. USB. Drivers work well enough. Low latency. Sorted.
Member since:2007-05-05
Member since:2005-11-14
Not really, unless you define 'serious' as 'serious amateur', using Fruityloops or Garageband or whatever kids like these days. On the other hand, 'serious' might be 'serious work', in which case things like Csounds or Ardour and Linux might be what you want to use.
There are plenty of musicians and audio engineers out there who aren't technophobic imbeciles.
Member since:2006-07-25
Member since:2006-05-30
Member since:2005-11-14
Member since:2005-08-18
Member since:
2009-12-10
I suppose you could have searched the Arch User Repository (AUR) before having a whole lot of work.
There is already a PKGBUILD ready to use for linux-rt, just download, tar xf, cd, makepkg, wait, pacman -U, adjust menu.conf, reboot. For that extra something there is linux-rt-ice which mixes the rt patched and tuxonice.
You really got to love Arch :p
Member since:2009-03-01
Member since:2010-01-11
I guess I can see the similarity...
Regardless, the OP was just pointing out that there's already a package for a realtime Linux kernel for Arch Linux, and therefore makes it pretty easy to install.
The other commands they included are just to tell GRUB to boot using the newly installed realtime kernel.
Edited 2012-04-13 12:58 UTC
Member since:2006-05-20
Member since:2005-07-11
Member since:2006-05-20
yaourt linux-rt
Everything else happens automatically, all nicely colour-coded and everything.
Not to get TOO far of topic, but any particular reason to prefer yaourt over packer + pacman-color? I went the latter route because that's what most of the ArchBang forum posts seem to use.
Member since:2005-07-11
Member since:
2011-05-31
Member since:2009-03-01
Member since:
2006-03-18
Member since:
2007-03-06
I don't remember finding so many complications back when I used to build my kernels on Gentoo, and I was a trained monkey with Google too.
Then again back then it took me about 8 hours to compile it, so getting a non working kernel because of some config options was a major PITA.
I guess I've always been lucky with Linux, from that first time I managed to install Debian (or was it redhat?) from floppies on first try, not even really knowing exactly what Linux was or what I would even want to do with it.
Member since:
2006-10-10
There's Debian package of kernel with rt. It's in squeeze-backports: http://packages.debian.org/squeeze-backports/linux-image-rt-amd64 .
apt-get -t squeeze-backports install linux-image-rt-amd64
Member since:
2012-04-13
Member since:2006-05-20
Member since:2005-07-11
Was just about to post the same:
Really? You couldn't install a package to make "make gconfig" work, so you abandoned the entire OS? Really? Instead of just typing "make menuconfig" and carrying on with your day?
Aren't techies supposed to be lazy?
How is installing a completely new OS, learning a new package manager, yadda yadda easier than typing "make menuconfig" after "make gconfig" fails?
Member since:2006-05-20
A ridiculous dependency loop is why I gave up on CrunchBang. Package managers are supposed to take care of this kind of thing automatically. The fact that I could have just not used those packages doesn't change the fact that CrunchBang was inherently broken. I don't want to take away from the difficulty of maintaining a distro, but when it fails so drastically out of the box, I don't see the point in sticking with it. There are so many options out there; why bother with something when it has such a glaring flaw?
Member since:2012-01-13
Member since:2006-05-20
ArchBang is what I went with. I'm fairly happy with it. I also seriously considered Lubuntu, which might be an easier migration from CrunchBang. Then again, I considered throwing a dart at the GNU/Linux Distribution Timeline.
http://futurist.se/gldt/wp-content/uploads/12.02/gldt1202.svg
Member since:
2008-06-03
Fwiw, I think the problem you had with libcairo and libpango not installing in Crunchbang was because;
A) Crunchbang already included patched builds with higher version numbers, (at least for libcairo) or
B) The builds currently installed were from Crunchbang's own repo, which was given higher pin-priority (apt-pinning) than the stock Debian Squeeze repos.
I've done my own compiling in stock Debian (albeit I run Sid ) and have had no issues in the past. Though, like the above poster, I prefer make menuconfig over make gconfig.
This sort of stuff is still more straightforward in Arch, imho. Though I'm talking about stock Arch, not derivatives like ArchBang which I have no experience with.
Edited 2012-04-13 02:37 UTC
Member since:
2005-07-06
Mod me down, I don't care. But.
I have to say, reading this has not been any fun. Or funny. Or interesting. I'd say such stuff would've been better placed in a low class linux newbie blog. The steps described and the things done would be ok if my art major sister wrote them. Otherwise, geez.
Seriously, this is how OSnews rolls now? Come on.
Member since:2006-06-28
Member since:2006-09-26
Member since:2008-10-28
Member since:2005-08-18
Member since:2007-03-26
I have to say, reading this has not been any fun. Or funny. Or interesting. I'd say such stuff would've been better placed in a low class linux newbie blog. The steps described and the things done would be ok if my art major sister wrote them. Otherwise, geez.
Seriously, this is how OSnews rolls now? Come on.
I'm inclined to agree as 3/4 of the article was about him distro hopping because the default behaviour wasn't what he expected.
Member since:2006-05-20
Member since:2012-04-13
There, there fella. Don't let haters get you down. I have no idea what in the world any of you are talking about. But Jimmy, keep on monkeying with this witchcraft and making the monies.
- Your friend John
PS. My little girl is about at the age where Dawnie learned to ski. Hint hint.
Member since:2010-01-11
This article was ok. I think the biggest thing is that, in my opinion, it doesn't quite fit in with the recent "feeling" of the articles on OSNews. There wasn't any news in it and there wasn't much of an opinion. It was just kind of a "here's something I did" article.
Instead, I think any lessons you learned about compiling a realtime kernel would be appreciated if you added them to a place like the Arch Linux wiki.
Member since:
2008-10-09
Immediately visible that Thom haven't had any Slackware experience. This is pretty much essential thing for Slackware to compile a custom kernel (although the stock one works fine). Slackware installation book covers this with enough detail. Also it is fine to see kernel panic first couple of custom compiles due leaving out a critical component.
Ultimately you will not have that dependency hell in Slack. Hate this when package manager tries to baby sit me. If I miss something I see the "library cannot be loaded... " message and that is enough to warn a missing piece I must install. Usually package managers demand unneccessary dependencies which actually does not prevent usage of the program. That is the reason why I like Slackware's approach because dependencies are usually not justified and I can sort them out myself if needed.
So I was hoping to see the RT kernel experience but this article was abiout custom kernel compilation. Dissapointed!
Member since:2006-05-20
I have to jump in here and point out that Thom didn't write the article, so the blame falls on me.
Sorry. Obviously, that was the long-term goal. I am currently torn between continuing towards that goal and just keeping my mouth shut. On the one hand, I'd like to redeem myself. On the other, I think that may not be possible.
-James
Member since:2008-10-09
Sorry about that very important missed detail that author wasn't Thom this time 
Sorry again!
Still I would urge you to continue the guest of RT kernels and perhaps recommend to try out a little hands-on linux where you have to make things working yourself. This way you learn what is important and what is not, You learn linux in general, not just that particular distro. After getting a bit customed with tinkering and all the command-line stuff suggest to start trying out to compile your custom kernels from scratch - beginning from clean config that is. After couple trial and errors you learn what parts of the kernel configs are important to you and which are not. For example, if you leave V4L part out of your kernel then it probably still continues to boot, but if you choose IDE controller on SATA system then you will be greeted with Kernel panic on next boot. If you haven't configured the boot loader with previous working kernel available, then that means reinstall Or if you are wizard enough, boot with some live CD, mount your partition, copy the working kernel with modules over there, configure boot loader and hope for the best. Linux is fun, if you have the time. Also you will learn A LOT.
Good luck and will be waiting for your RT kernel article still with all the comparisons, where it is better and where it is worse.
Member since:
2007-04-13