Slashdot Mirror
Kernel 2.4.17 Out
ThatComputerGuy writes "Linux kernel 2.4.17 is final, with a lot of fixes/updates. Check out the huge changelog. If you're on a desktop machine, you should try using RML's preempt patch, it definitely helps response times."
← Back to Stories (view on slashdot.org)
I used the preempt patch back when 2.4.14 was released and I kept getting consistent kernel panics. Mind you, I'd also applied an -ac patch, so I can't say for certain that preemption was the cause, but it was troubling and the panics went away once I disabled preemption.
STOP MISUSING APOSTROPHES, YOU MORONS!!!
You will want to wait until RML releases the finale preempt patch. It will just be the kernel version (2.4.17) without the rc on the end. His patches are very version specific.
Pbur
A bios upgrade fixed the problem for me. Look for an update on your motherboard vendor's website.
get the patch
WWJD? JWRTFM!!!
I have mirrored the patch and signature:
. bz2
. bz2.sign
patch-2.4.17.bz2 (388KB): http://home.earthlink.net/~noodlez84/patch-2.4.17
patch-2.4.17.bz2.sign (1KB): http://home.earthlink.net/~noodlez84/patch-2.4.17
Does it work with the KT133a Chipset and Athlons?
This was a long standing motherboard/BIOS issue. I think VIA actually found and acknowledged that some register was getting scrambled inadvertantly but I could be thinking of another peice of hardware. It's so hard to find these messages in the lkml archives even after only a few days. At any rate, I have this board. At one time I had problems but it was difficult for me to tell if it was the VIA board or the infamous IBM Deskstar 30GB drive I had that was failing. So I RMA'd the drive, bought another SCSI drive and put my 2940UW on there with the latest BIOS update. I have not had any problems since and I tortured it pretty hard. Of coure all of this is off topic because I'm using Red Hats 2.4.7 but again, this is/was a hardware/BIOS issue.
Lack of solid documentation and licensing issues as I remember.
Mad Software: Rantings on Developing So
Well, if you have checked the linux-ntfs website, especially the mailing list archives you would see this question comes up a lot.
Here's one reply to why it hasn't been done yet.
Hail to the king, baby!
What are you talking about?
The message is about SSE being enabled on AthlonXP's.
It doesn't work on 'normal' Athlons!
The patch makes a big difference for me when using latency-sensitive software (xmms) while I'm really pummeling my system (big compile).
xmms usually skips a bit while I'm compiling something large, but it hasn't even once after applying the preempt patch.
I haven't noticed performance degredation from any effects on throughput, so it's all good here.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot
It definitely makes a difference on my (400Mhz) system. I suspect, however, the faster your system, the less noticeable the effects will be, since it'll take less time inside the kernel regardless of whether the kernel can be pre-empted or not.
That said, the patch is, architecturally, a good thing, as making it work better automatically makes SMP work better, and vice versa. I think it should go into the offical kernel in the 2.5 cycle, personally - even on servers, it often matters that clients are responded to quickly, to keep people at a website, say, rather than sending the absolute max amount of data down the line - so even if the preempt patch has a slight negative impact on total throughput, it's a win for responsiveness.
Having a preemptive kernel just means that the kernel will allow itself to be interrupted by other programs and give them some cpu time.
This improves response time for your programs as now they won't get stuck waiting for the kernel to finish doing something time-consuming (like disk I/O) before they get some cpu cycles.
In most cases this isn't a big deal, but you'd definitely notice when your mp3 player skips because it's stuck in line behind the kernel.
"Where shall the word be found, where will the word resound? Not here, there is not enough silence." -T.S. Eliot
When a process starts a kernel call, it will not be context-swapped until it finishes executing the call. That is, the kernel will not change the executing process as long as it is kernel code that is in execution. There are many reasons for this. The patch makes it OK to to context swapping in the middle of kernel execution, helping all processes get an equal amount of CPU time.
My MP3s stopped skipping under heavy(ish) load. For example, when checking out the Mozilla tree, there is a lot of hard disk access for up to a minute. During this time, XMMS would often skip and crackle, whereas with the preempt patches this no longer occurs.
Xine also seems to like the patches. I can often have two compiles going on in the background with a fair bit of swapping and DVD playback is still smooth. This was not the case without the preempt patches.
In general, the preempt patches help if you use your system as a desktop/workstation, it could actually harm system performance if it's primarily a server.
at least you realized you asked something stupid... :)
the trickiest part is figuring out that you need to use "patch", there's also the README file in the root of the linux source that I believe gives you instructions
-- gid
You should try out /dev/bios. It's a very cool little kernel module. I recently used it to flash the bios on one of my linux boxes that didn't have a floppy installed. Just cat the file out to /dev/bios and reboot. It's a beautiful thing, though obviously you probably wouldn't want to have it installed all the time :-)
MPlayer makes use of MMX and 3Dnow! if they are available. Makes my K6-III+, 400 MHz, play DivX quite well :-)
Escher was the first MC and Giger invented the HR department.
There are two things here. Preemptive in userspace, and preemptive in kernel space. Linux is preemptive in user space, meaning that when a process is running application code, it can be preempted. When it is running kernel code, however (ie. during a system call) the scheduler will not preempt the thread, even if a higher priority one becomes available. Essentially (on a single processor) the kernel code is cooperatively multitasked. Kernel code runs until schedule() is called to invoke the scheduler. Some kernel code paths are very long, which leads to long periods where the current process cannot be preempted, which kills latency.
Also, to expand on the original question, there are a couple objections to the patch: It has the potential total throughput, because more locking must be used since the kernel can be preempted at any time, not just at specified points. However, in practice, the effect on throughput seems to be negligible. It also increases complexity, due to additional locking, but most of the complexity is there anyway, in the form of the SMP locks.
A deep unwavering belief is a sure sign you're missing something...
> I don't understand the difference between preemtive and the normal way (btw: which?).
The normal (old) way is "cooperative" -- meaning you don't yield a task until you're ready.
Pre-emptive means you can be forced to give up your task.
The thing about RedHat with newer kernels make sure that you sym link include/linux in source dist to /usr/include/linux to make sure you have the proper headers when you compile modules.
/usr/src/linux which is itself a link to the current linux source dist.
/usr/include which I think is nasty.
Also sym link asm, asm-i386 or anything else you may need form the include directory in the linux kernel source dist.
I usualy link these to
I don't know if there's an easier way of doing this, but it seems that RedHat just copies header files from the kernel that it comes with into
This guy is right - the workaround for the problem has been about for a while. For more information on the problem take a look at the Via Hardware FAQ. The whole via problem has been known about for sometime (a search on Kernel Traffic for KT133 turned up a few references. The most recent reference was 2.4 Kernel freezes on VIA KT133.
As mentioned in other comments, motherboard makers were encouraged to workaround this at bios level.
Download and compile eepro100-diag.c from the Scyld website then follow Donald Becker's instructions here.
Ah! Partially right! But sorry, no dice. The only cooperative multitasking that is done in Windows 9x is with 16 bit applications, since all 16-bit apps are run in the same virtual machine. All 32-bit apps are fully preemptively (userspace multitasked. As for memory protection, that's only partially true. Application memory is indeed protected from each other. However, there is a big 1GB region of shared memory that is unprotected. Apps that use this region and asking to hose the system. Also, some bits of kernel memory are unprotected because DOS apps need access to them.
As for NT, it is a fully preemptible kernel, both in userspace and kernel space. Like all preemptive kernels, of course, it is not preemptible when interrupts are disabled (since the clock interrupt can't happen). The main reason why NT has always been preemptive is because its always been SMP. The locking requirements on SMP are similar to to locking requirements for a preemptible kernel, so you can get both together for the price of one. Indeed, the preemptive patch for Linux is very small because it uses the existing SMP locking mechanism.
A deep unwavering belief is a sure sign you're missing something...
I use Debian source kernels; the trick is to copy .config from the old tree to the new one, then connect to the new tree and make oldconfig. Voila', you only answer the new questions; all your existing settings get setup automatically. Build as usual from this point.
Appears to be a known problem when compiling with RedHat's prerelease of the GCC 3.1 compiler.
Here is some more information. In general, I recommend that you do not attempt to compile the Linux kernel using any version of GCC newer than 2.96.