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!!!
Ive got dibs on putting the star on top
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
I haven't looked at the changelog yet, but I'm sure that there's a line reading something like
/promise/ not to corrupt filesystems when you 'umount /mnt/tmp/lifes_work'."
"This time we
All the same, many kudos to the kernel guys for giving me something new to play with for the holiday!
--
I Hit the Karma Cap, and All I Got Was This Lousy
It looks like we're actually seeing 99% bug fixes this time around, rather than new features being added. Yay for having a 2.5 branch, it seems to be getting the experimental code now. This may be the first 2.4 kernel I compile for my system (I'm not saying I'm still stuck in 2.2, just that I've kept the default 2.4 kernels from my Mandrake and SuSE installs). I also see a couple ext3 fixes, which means I'm pretty comfortable having this replace the patched-to-use-ext3 2.4.10 kernel in my SuSE 7.3 box.
My Greasemonkey scripts for Digg &
Does it work with the KT133a Chipset and Athlons? I looked and google and there were reports of the problem, but no report of a fix anywhere that I could find.
you don't HAVE to upgrade your linux box, either. but at least you have the OPTION of upgrading for FREE, instead of paying year after year if you want to upgrade.
as you said, you are happy with win98, more power to you. but many people are not happy with windows and have to shell out big bucks every couple years to upgrade.
yeah, i know, the post was flamebait. but hey, i'm a sucker for anything this obvious.
-sam
burn the computers. go back to the abacus.
Looks like the new kernel maintainer is really working out. I enjoy seeing these kind of detailed changelogs, to determine whether there is anything critical enough to upgrade my system.
Seems like Alan and Linux lately haven't been all that hot about doing the drudge detail work. This arrangement seems to be the best solution for everyone.
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
Has anyone actually tried this and noticed a difference? I was under the impression that a lot of people thought this was useless.
http://www.masturbateforpeace.com/
Ha! 2.2.18 on december 11, 2000. 2.4.0 in january, 2001. That means, roughly, 1.5 versions of 2.4 per month, while we have only 1 version of 2.2 in 6 months.
Somewhere in april we'll have 2.4.21 and 2.2.21 and one month later, 2.4.22 will be out. Hooray!
my other sig is a 500 page novel
After several of the last few kernels being released with major bugs, I thought the consensus on LKML was to use -rc versions for bugfixes, and then release a 'final' without making any changes in it. Yet, when I read this changelog, I see that changes were made in the final version. A lot of people will only download a 'final' kernel, because they think that it contains only tested, stable code. That is what the -rc system was to ensure, but releasing a 'final' with changes means that a partially untested kernel is being released to the unsuspecting public. Now, I will admit that there's a very good solution that any user can implement - just don't upgrade. However, these recent quality control problems have given Linux something of a black eye in the public's mind. Therefore, it just seems common sense to not release a kernel with code that hasn't been in for at least one -pre or -rc revision. So, if I were a kernel maintainer, about to release kernel 2.4.18, and I received a 'critical' patch from a project maintainer, I'd make one last -rc release to ensure that the code gets tested before I release it. However, I'm not a kernel maintainer, so take this as you will. I don't mean it as a flame, and I think that Linus and Marcelo have done a wonderful job so far with Linux 2.4.
From pre1:
:o)
- Speeling fix for rd.c
Gotta love that sense of humor (at least I HOPE it was intentional
Any word on what the NTFS bug fixes involved? Any closer to a usable readwrite mode?
Mad Software: Rantings on Developing So
in the changelong I noticed...
pre5 - Enable K7 SSE (John Clemens)
So we now have SSE for the K7 cpu? Does any programs on linux even take the extra speed of SSE/MMX/3D NOW? I have always wondered since these type of optimizations are only visible when the software application lists it, and most software is for windows.
I guess then they will be just like Apple charging for OSX upgrades.
Well, why don't you try the source provided for you by your distro, it should have all the distro changes, in it. Then see if you can get the patch to work. If you can't, find a linux guru who can do it for you, and publish the patch, many people will love you :)
final:
- Fix more loopback deadlocks (Andrea Arcangeli)
the very first line of the changelog is scaring my ass of. this sounds like there are some / an unknown number of loopback deadlocks still lurking and nobody knows where, until it jumps out to rip your head off.
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.
In fact, *only* Linux users have to upgrade their kernel every so often.
Users of proprietary OSes don't have a chance to, and users of about
any other Free OS - well most other free OSes kernels just aren't
broken every second week.
Programming can be fun again. Film at 11.
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.
Neither have Linux users.
Did I miss something? Did Bill Gates redefine the english language so that "be able to" and "have to" mean the same thing? Why don't Windroids understand the difference then?
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 :-)
I noticed someone else asking about VIA KT133 support, so I thought I'd inquire about the KT266A...
We have two new office-brew systems, one mobo from Asus and one from Abit, both are based on the KT266A and neither will boot any flavor of kernel 2.4.x that we've thrown at it. I've done the normal google and usenet searches, but haven't found much other than a few "works for me" posts. Anyone have some pointers or patches?
damn, man! Why is this rated 'funny' with _every_ kernel release? Or am I the only one noticing/nagging?
Something I feel like asking as 2.4.17 (bz2) trickles down the connection at 0.2K/sec from Australia's Planetmirror...
The kernel's are posted in both GZ and BZ2 formats. What do you guys mostly use? I can't see much point these days with having the Gzip format, I mean is there still a point to downloading it? Or even having them available in that format?
From what I can see, removing the Gzipped versions
*reduces network congestion
*saves space on the mirrors
*saves space on local storage (yeah only a couple megs)
Of course, it requires more processing time to extract, but that seems to be no big deal these days. I'm pretty sure everyone has bzip2 installed , and those who don't can easily get it, so that can't be a problem.
So is it really just traditional reasons it's posted in Gzipped format? Tell me if I've missed something. It would be interesting to know what everyone thinks about this.
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've got it. I'm trying to compile it. It fails at make bzImage compiling network.o. See the snippet.
/opt/kernel/linux-2.4.17/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_tas
/opt/kernel/linux-2.4.17/arch/i386/lib/lib.a /opt/kernel/linux-2.4.17/lib/lib.a /opt/kernel/linux-2.4.17/arch/i386/
Anyone know how to fix it?
ld -m elf_i386 -T
k.o init/main.o init/version.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \
drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char
/agp/agp.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/d
river.o drivers/pnp/pnp.o drivers/video/video.o drivers/md/mddev.o \
net/network.o \
lib/lib.a \
--end-group \
-o vmlinux
net/network.o: In function `__rpc_schedule':
net/network.o(.text+0x49a0d): undefined reference to `rpciod_tcp_dispatcher'
make: *** [vmlinux] Error 1
"RML"? Robert M. Love stole my initials! Now I have to worry about people confusing me with someone who knows what he's doing.
Human/Ranger/Zangband
I've been using linux since the very early 2.0.* days and for the most part I keep up with every kernel released. Since I've moved to 2.4.*, I've notices an incredible slowdown on my machine, even in post-2.4.13 kernels which supposedly did something to improve performance.
Personally I'm about ready to go back to good old fast&stable&reliable 2.2 tree. I wonder if we really need to make the kernel this sluggish for the sake of introducing new stuff in the kernel level though. I know I'm not the only one who noticed the performance drop with 2.4.*.
--
> 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.
That's not *quite* right. Linux has been pre-emptive since the beginning, but in userspace, not kernelspace. IE, system calls, driver code, and other kernel stuff couldn't be preempted, but user code could.
Windows, on the other hand (9x, I don't know about NT) is fully cooperative, meaning that userland isn't preempted either. That, and poor memory protection, is why buggy windows programs can bring the system down, Whereas in linux, only kernel space stuff can lock up the system.
The preempt patch, then just makes the kernel preemptable, so that Linux is fully preemptive, instead of just in userland.
Fish
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.
I installed the patch, recompiled and both ALSA 5.12a and nvidia's kernel module were broken. I got unresolved symbols.
It would be nice if there was some way to exempt these two from the optimization or there was a doc explaining what I would need to change
Because they have a sane versioning system and don't try to be all 'leet and artificially keep their version numbers down! What is it about OSS developers that makes them dispise version numbers above 1.0?
A deep unwavering belief is a sure sign you're missing something...
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...
Hey, I love BeOS as much as the next fanatic, but (as much as I would love to) I can't use it because its compiler is old and there is no support for the rear-channel on my SB Live!
A deep unwavering belief is a sure sign you're missing something...
lately try using win 95 as a firewall/dns/router on a 386?
have fun.
-sam
burn the computers. go back to the abacus.