Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Kernel 2.4.17 Out 350

Posted by CmdrTaco from the download-compile-reboot-repeat dept.
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."
This discussion has been archived. No new comments can be posted.

Kernel 2.4.17 Out More

Kernel 2.4.17 Out

Comments Filter:

  • Instability with the preempt patch? (Score:3, Informative)

    by Dimensio ( 311070 ) <darkstar@LISPiglou.com minus language> on Friday December 21, 2001 @05:22PM (#2739079)
    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.
    • I've applied the the preempt patch along with win4lin patch to a 2.4.14 kernel and experienced no kernel panics, no stability problems. I am not sure, however, if i have seen any positive effect from having this patch applied. it hasn't hurt, at least...

    • Re:Instability with the preempt patch? (Score:5, Informative)

      by KnightStalker ( 1929 ) <map_sort_map@yahoo.com> on Friday December 21, 2001 @06:16PM (#2739354) Homepage
      I had similar problems with 2.4.14 and the kernel preemption patch, but I'm running it against 2.4.16 right now with spectacular results. I can play a DVD full screen when the system load (i/o bound) is greater than 3 on my single-Athlon 900. No skips, pops, jumps, anything. Smooth as silk.
    • I had some problems, too. I ran RML patch on 2.4.14 on an k6-III and I've experienced strange locks of the system (Slackware 8.0 with some updates). Suddenly everything freezed and remained blocked for about a minute, then everything got back to normal. It could happen around one time every two hours. After I updated to 2.4.16 (and didn't install the RML patch), I've never experienced this kind of problems (but my gateway's Davicom ethernet card seem not to like the new kernel very much).

    • Re:Instability with the preempt patch? (Score:5, Informative)

      by Spoing ( 152917 ) on Friday December 21, 2001 @07:05PM (#2739574) Homepage
      Make sure that any kernel modules you load are SMP-safe. While the preempt patch does not magically make a uni-processor system into a multi-processor, it does create an environment where modules that aren't SMP-safe tend to fail or act unusually.

      Rule of thumb: If it's in the base kernel sources, you're OK. If it's a patch to the kernel sources, be careful but not overly concerned. If it's a pre-compiled binary (even if only in part), be very cautious. Remember: Google is your friend.

      Example: The Alcatel external USB DSL modem, for example, has a binary part that isn't fully SMP-safe. Because of that, it can't be used with the preempt patch even on a system with a single main CPU.

  • Ive got dibs on putting the star on top
  • From the changlog:

    Jeff Garzik is not the via82cxxx driver
    maintainer anymore: "No time, no hardware".

    So who's gonna do it? Am I an idiot or is that a fairly common chipset among linux users?

  • Wait for Final Preempt patch (Score:3, Informative)

    by pbur ( 88030 ) on Friday December 21, 2001 @05:26PM (#2739099)
    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

  • Changelog...? (Score:3, Funny)

    by Hiro Antagonist ( 310179 ) on Friday December 21, 2001 @05:26PM (#2739102) Journal
    I haven't looked at the changelog yet, but I'm sure that there's a line reading something like

    "This time we /promise/ not to corrupt filesystems when you 'umount /mnt/tmp/lifes_work'."

    All the same, many kudos to the kernel guys for giving me something new to play with for the holiday!

  • It appears to actually be fixes (Score:5, Interesting)

    by Anthony Boyd ( 242971 ) on Friday December 21, 2001 @05:27PM (#2739111) Homepage

    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.

    • Well, it's gonna be a while before I try 2.4.anything on a production machine.

      On the one hand, I'm glad to be seeing a lot of bugfixes in the changelog. On the other hand, I'm worried about seeing lots of bugs in the changelog, because I wonder how many more serious ones are lurking in the codebase.

      With 2.2.whatever, the bugfixes there have been recently have mostly been related to specific drivers, which I usually don't care about (unless I'm using that driver). But with 2.4.x I'm still seeing lots of fixes in the main kernel code, because so much fundamental structure has changed since 2.2.

      I guess we'll have to see. Maybe if some decent RAID card support starts showing up in OpenBSD, I'll think about switching my servers to that.

      • 2.4.10, 2.4.13, 2.4.16 have all been fairly stable on my desktop workstation.

        The fact that 2.4.17 was ALL bug fixes is a good sign. It means that they are fixing the issues that they know about, like parport IEEE1394 seems to work better.

        I see no reason not to use 2.4 at this point on a produciton machine. It is not until people do start doing so that we are going to find out all the kernel issues. I'd recommend trying this release if no other.

  • VIA KT133 chipset? (Score:3, Interesting)

    by blogan ( 84463 ) on Friday December 21, 2001 @05:27PM (#2739114)
    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.

    • Re:VIA KT133 chipset? (Score:5, Informative)

      by MikeO ( 951 ) on Friday December 21, 2001 @05:32PM (#2739145) Homepage
      A bios upgrade fixed the problem for me. Look for an update on your motherboard vendor's website.
      • how do you upgrade a bios in Linux??

        Also does anyone know if they fixed the parport problems?

        To answer your question about KT133, there is a bug on the VIA chipset that causes some people problems.

        In my case and a few others there are IDE bugs. IDE IOMEGA zip 100 and VIA686B don't go togeather to well.

        Also some people have had problems with using the ECC/ECP part of the parport. Again, in my case it was my webcam did not work. It stopped working in 2.4.13 or 14 not sure. I had a fix for it and explained on the lkml what the problem was, but not sure if that was ever acknowledged.

        Well now I have a very good testing mechanism for testing kernels like this. I have a foo.test kernel and a foo.custom kernel. The custom kernel is the current kernel and the test is, well a test kernel. Nice thing about lilo is you can have multiple kernels. I can then boot the test kernel and make sure all works on my system. I'll be doing that tonight...

    • What is the problem? I looked at Google as you mentioned but didn't see what you were talking about.

    • Re:VIA KT133 chipset? (Score:2, Informative)

      by KidSock ( 150684 )
      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.
    • I have a board (ASUS A7V133) with a KT133A+T-Bird 1.33 and haven't experienced problems with any kernel I tried so far (2.4.5, 2.4.7, 2.4.8, 2.4.10 and 1.4.16). The only problem I've heard (never experienced it) with my bord was actually the VIA (866B?) southbridge.
    • The fix was included somewhere before 2.4.16. It disables a single bit in a undocumented PCI register, fixing most problems.
  • I want to try the preempt patch but I finally got a kernel from my favorite distribution that works for me right out of the box. To get a raw kernel with all the stuff that I want plus the preempt patch I'll have to spend more time than I have patching and compiling. I hear how great this patch is about once a month. Why isn't it included in the major distros? Would it "harm" in any way my desktop/server running X, KDE, FreesWan, Apache, Samba, etc?
    • 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 :)

  • New Maintainer (Score:4, Insightful)

    by krackbebe ( 545104 ) on Friday December 21, 2001 @05:29PM (#2739126) Homepage
    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.

  • patch mirror (Score:3, Informative)

    by noodlez84 ( 416138 ) on Friday December 21, 2001 @05:42PM (#2739197)
    I have mirrored the patch and signature:

    patch-2.4.17.bz2 (388KB): http://home.earthlink.net/~noodlez84/patch-2.4.17. bz2
    patch-2.4.17.bz2.sign (1KB): http://home.earthlink.net/~noodlez84/patch-2.4.17. bz2.sign
  • Im running the 2.5 kernel and it seems as snappy as the 2.4.blah with the preemptpbile kernel patch-- winamp doesnt skip even when burning cd's and starting mozilla... is there something different here? besides that i cant find the preemtpaible kernel patch for 2.5
    • if you are running after a 2.5.1-pre3 then the bio changes are what's making most of the difference, better io scheduling and consistant buffer handling..
  • Has anyone actually tried this and noticed a difference? I was under the impression that a lot of people thought this was useless.
    • I've tried the preempt patch and not noticed a difference either...

      maybe what we need is someone to give us some concrete, real world examples of where the preempt patch would do some good? Then we'd know if it would make much of a difference for what we use our systems for...
      • 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.

    • Re:Preempt Patch? (Score:3, Informative)

      by itarget ( 168249 )
      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.

    • Re:Preempt Patch? (Score:2, Informative)

      by Anonymous Coward
      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.
    • Preempt made my system (around 2.4.9 or so) noticeably slower.

      -Legion

    • I installed it on 2.4.14 and I didn't notice a single bit of difference.

      BUT, I'm also not doing anything that can really take advantage of it. I don't play music or movies. The most I will ever do is run vi and gcc at the same time.

      So, it depends on what you do with your machine. The patch seems to work for people who want to play video on a machine with a high load.
    • Good question.

      I never used the preempt patch, because I'm on a smp system, and it would make it rather unstable.

      But from what I hear, it helps with latency problems, but has a decrease on throughput.
      So I'm wondering, just increasing the latency does do exactly the same, doesn't it?
      I mean, I increased the latency on the pci bus, and my mp3's are almost never skipping anymore. Which is the same claim made by lovers of the preempt patch.
      I never use video stuff though, so I can't comment on that.

      For changing the latency, you can find a good read here:
      Latency [ibm.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!
    • Kernel development is a funny beast. Sometimes, things just work, and kernels only have to be released when there's a significant amount of hardware. Other times, things don't work and you have to put out a lot of fixes - the early days of the 2.4 VM system sucked; it only started to really rock about 2.4.10 or so. What you didn't take into account with your guestimates is that kernel 2.2.x also had some growing pains in the early stages; it just took a bit longer for 2.4.x to get stable. Just take into consideration the 2.0.x series, they're getting close to a .40 for that line. Trust me, 2.0.x is still being used; there are some vendors who supplied binary-only patches for the 2.0.x series which don't work with the newer lines.
    • That's the way it is supposed to work. As a program matures, there will be less updates, and things to fix. I thought this was a pretty basic concept...
  • Don't forget to use the mirrors [kernel.org].

  • Misguided versioning? (Score:4, Interesting)

    by kurtras ( 65722 ) on Friday December 21, 2001 @05:52PM (#2739245) Journal
    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.
    • I dissagree, 2.2.x series was handled in a similar fashion as the 2.4.x is now. so one could really say that the lack of a development kernel to let the "kids" play with their new patches is what really hurt 2.4 so far. cause if you hadn't noticed, most of the changelog is BUGFIXES.

      I just remembered... RTFM (or RTFL in this case) archives can be found on the web.
  • From pre1:

    - Speeling fix for rd.c

    Gotta love that sense of humor (at least I HOPE it was intentional :o)

  • Cache/Buffer Fixes (Score:1, Interesting)

    by Mish ( 50810 )
    I don't know if anyone else is as happy as I am right now to see these fixes in the changelog...

    - Make kernel try a bit harder to shrink caches
    instead swapping out
    - Fix VM problems where cache/buffers didn't get
    freed

    The 2.4 series has been plagued by these problems, thank god that they might finally be over...

  • NTFS bug fixes? (Score:2, Interesting)

    by Mr. McGibby ( 41471 )
    Any word on what the NTFS bug fixes involved? Any closer to a usable readwrite mode?

  • AMD K7 SSE (Score:3, Interesting)

    by BrookHarty ( 9119 ) on Friday December 21, 2001 @06:05PM (#2739311) Journal
    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 wonder what kernel slashdot uses on it's servers.
    are up to 2.4 yet? Or still running 2.2?
    If they are still running 2.2 when will slashdot upgrade?
  • I don't understand the difference between preemtive and the normal way (btw: which?). Could someone explain this to me? What are the advantages? Thanks, Hermi
    • 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.
    • 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.
    • > 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.
        • 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.

  • loopback deadlocks (Score:2, Interesting)

    by Anonymous Coward
    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.
  • 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?

  • BZ2 vs GZ (Score:4, Interesting)

    by jquirke ( 473496 ) on Friday December 21, 2001 @09:18PM (#2739965)
    Something I feel like asking as 2.4.17 (bz2) trickles down the connection at 0.2K/sec from Australia's Planetmirror [planetmirror.com]...

    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.
    • Tradition, some people don't have bunzip2, and BZ2 takes longer to decompress (a real issue on slower systems).

    • Re:BZ2 vs GZ (Score:3, Insightful)

      by TaliesinWI ( 454205 )
      I'm sure I'm going to be showing my age when I say that I remember the Big Switch from .Z (Compress format) to .gz on most FTP sites. Is .bz2 really becoming that common? The only place I'm really exposed to it are the kernel sites, most other source code repositories are either just .gz or still have legacy .Z stuff lying around...

    • Re:BZ2 vs GZ (Score:2, Interesting)

      by Gregg Alan ( 8487 )
      I only use bz2 for the kernel. Seems to me that processing power is cheaper than bandwidth (lucky for me I have plenty of both.)

      If the extra time to decompress a bz2 over a gz is that great a factor, why would you even want to compile a kernel on that particular machine? Compile it on your fast box and just copy it over. That's what I do.

    • Re:BZ2 vs GZ (Score:2, Interesting)

      by Ed Avis ( 5917 )
      If you're worried about download time, just get the patches!

      (Okay that only works if you've got the previous version - you can download a whole sequence of patches for bigger jumps, but after a while it gets bigger than the kernel itself. I'd like to see a general patch generator where you type in what version you currently have and it generates the smallest patch file just for you. Alternatively some way of using rsync would save on bandwidth.)
  • I've got it. I'm trying to compile it. It fails at make bzImage compiling network.o. See the snippet.

    Anyone know how to fix it?

    ld -m elf_i386 -T /opt/kernel/linux-2.4.17/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_tas
    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 \
    /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/
    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
    • Appears to be a known problem when compiling with RedHat's prerelease of the GCC 3.1 compiler.

      Here [google.com] 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.

  • Another RML? (Score:3, Funny)

    by RML ( 135014 ) on Friday December 21, 2001 @10:55PM (#2740135)
    "RML"? Robert M. Love stole my initials! Now I have to worry about people confusing me with someone who knows what he's doing.

  • 2.4 (Score:2, Interesting)

    by Arjuna Theban ( 143564 )
    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 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

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close