Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Upgrades Software Linux

Linux Kernel 2.6.8 Released 203

Posted by CowboyNeal from the compile-reboot-repeat dept.
J ROC writes "According to The Linux Kernel Archives kernel 2.6.8 is now out. It includes some fixes from 2.6.7. Happy upgrading." You may want to read this earlier story and think twice before upgrading.
This discussion has been archived. No new comments can be posted.

Linux Kernel 2.6.8 Released More

Linux Kernel 2.6.8 Released

Comments Filter:

  • I'm waiting on SP2 (Score:5, Funny)

    by Anonymous Coward on Saturday August 14, 2004 @08:17AM (#9966745)
    Because we all know no OS is stable without a few service packs applied.

  • 2.6.8.1 is really the latest (Score:5, Informative)

    by scotsgit ( 792029 ) on Saturday August 14, 2004 @08:21AM (#9966758)
    Due to an NFS bug a brown paper bag release was produced.

  • Download from mirror nearest to you (Score:3, Informative)

    by anandpur ( 303114 ) on Saturday August 14, 2004 @08:21AM (#9966760)
    Mirrors [kernel.org]

  • 2.6.8.1 (Score:5, Informative)

    by calibanDNS ( 32250 ) <[moc.liamtoh] [ta] [notats_darb]> on Saturday August 14, 2004 @08:26AM (#9966780)
    The latest is actually 2.6.8.1. The (very short) change log for that version can be found here [kernel.org]. Looks like there was an NFS bug in the 2.6.8 release that needed to be fixed.

    • Re:2.6.8.1 (Score:4, Insightful)

      by ThisNukes4u ( 752508 ) <tcoppi AT gmail DOT com> on Saturday August 14, 2004 @08:29AM (#9966791) Homepage
      I guess they were really serious when they said that the stabilization of the kernel was up to the distro maintainers. Guess I won't be downloading 2.6.8 until 2.6.9 comes out.

      • Re:2.6.8.1 (Score:4, Interesting)

        by bfields ( 66644 ) on Saturday August 14, 2004 @08:56AM (#9966893) Homepage
        I guess they were really serious when they said that the stabilization of the kernel was up to the distro maintainers. Guess I won't be downloading 2.6.8 until 2.6.9 comes out.

        They've been saying for some time that they'd also release small updates (like 2.6.8.1) against previous releases when necessary, so it should be reasonably safe to take a recent kernel if you wait a couple weeks after the major release and check for any such updates.

        For what it's worth, I've been upgrading on every major release (and most of the -rc's too) since 2.6.0, without any disasters.

        Of course, depending on which particular drivers you care about and so on, your mileage may vary.

        --Bruce Fields

        • One of the 2.6.x set (I think it was 2.6.4) would not boot for me. I think it was a problem with the IDE drivers.

          Most of the time I wait for Slashdot to announce the kernel and check for comments announcing bugs. This time I did not bother waiting, but got lucky in that 2.6.8.1 was already available by the time I came to download.

      • Re:2.6.8.1 (Score:3, Insightful)

        by sloanster ( 213766 ) *
        I guess they were really serious when they said that the stabilization of the kernel was up to the distro maintainers.

        LOL, the sky is not falling...

        99.9% of linux users do not build their disto from scratch, but get their distro from a vcendor, so this means absolutely nothing for the vast majority. Those that are smart enough to build their own kernels, are also smart enough to follow the kernel mailing list and apply patches.

        I've been running 2.6 kernels from kernel.org as well as -mm kernels on my FC
      • Guess I won't be downloading 2.6.8 until 2.6.9 comes out.

        If 2.6.9 is out, I recommend you download that, not 2.6.8.

  • Has the 2.6 branch been patched with exec-shield yet? I know there is some compatibility issues, but Linus said he was going to allow it anyway.

  • Summary? (Score:4, Insightful)

    by tweakt ( 325224 ) * on Saturday August 14, 2004 @08:29AM (#9966794) Homepage
    I scanned the Changelog briefly and didn't see anything major. I usually grep for 'thinkpad' or 'laptop' (my main system), to see if there is anything nice to try out. There are some laptop_mode improvements (disk IO buffering, keeps hard drive spun down for as long as possible) which should benefit any laptop user.

    On occasion, someone will write up a nice summary of highlights. Anyone seen such a thing for 2.6.8?

    • Re:Summary? (Score:3, Informative)

      by Zarhan ( 415465 )
      On occasion, someone will write up a nice summary of highlights. Anyone seen such a thing for 2.6.8?

      Kerneltrap [kerneltrap.org] usually posts one shortly after release. Not yet posted for 2.6.8, though, but check periodically, I would think that they will update later today.

      • Re:Summary? (Score:5, Informative)

        by Anonymous Coward on Saturday August 14, 2004 @09:19AM (#9966976)
        Lots of memory leaks fixed.
        Lots of USB issues fixed.
        A few patches for prism based wireless card too.
        Several filesystem patches:
        EXT3 deadlocks removed and buffer issue fixed.
        EXT2, Reiser + JFS I/O errors lost issue fixed.
        Network oops, I/O oops created in 2.6.7, smbfs + nfs oops, SATA + Highmem oops
        X86_64 Memory corruption fix's + "small + serious" bugs.
        New hardware support for latest VIA K8%, KT%, VT%, PM% chipsets.
        NX (No eXecute) support for x86
    • I wonder if your laptop_mode experience is like mine - it hardly makes any difference at all? I already had cpufreq going to control cpu speed, and get good battery life from my T40. But using laptop_mode to let the disk drive spin down makes hardly any difference - at most 10 minutes on top of the normal 4 hours or so. (And I was monitoring the drive with "hdparm -C /dev/hda" to make sure it the drive really was suspended.)

      Adjusting the screen brightness makes a slightly larger difference, but not muc

  • Download Size (Score:5, Interesting)

    by RAMMS+EIN ( 578166 ) on Saturday August 14, 2004 @08:42AM (#9966833) Homepage Journal
    I'm repeating this message from OSNews [osnews.com], which had the story first.

    I think Linux is a great kernel, but a 42 MB download is really a bit too much for my liking. Much of that is code for hardware that I don't have or features that I don't want. I am a great advocate of modularity, and I would like to see it applied not only to the compiled kernel, but also to the sources. I am aware that this will add some administrative overhead, but it could save a lot of traffic and CPU time.

    Here are some ideas:

    - Split the distribution in a base that has the common stuff, and optional add-ons for lesser-used network devices, filesystems, etc. etc.

    - Employ a BSD ports like system that downloads the sources on request (i.e. when compilation of some part is requested)

    - Distribute only the configuration interface, and download only the parts actually needed based on the configuration selected.

    I am too occupied now to come up with a proper proposal, but I hope this will set some people thinking.

    • Re:Download Size (Score:3, Interesting)

      by Anonymous Coward
      That would probably ultimately result in the definition of a stable module interface between the linux kernel and device drivers. This has been explicitly stated as a non-goal by Linus for his tree as it would facilitate the production of closed-source hardware drivers, and we/he wants to "encourage" open-source device drivers (quite rightly IMHO, but I disagree with his method*).

      * I think a stable module interface might be _good_ for open-source drivers - hardware manufacturers may never produce their own
      • LOL. "It might stabilize the API" has to be the worst objection I've ever heard.

      • Re:Download Size (Score:3, Interesting)

        by obi ( 118631 )
        Actually, no - it's not that they want to discourage closed-source drivers, it's just that they don't want to be prisoner of this "stable api" for the sake of some closed drivers.

        They basically want to have the freedom to evolve the api as they see fit - and sometimes there's good reasons for changing it. If a stable API means being stuck with the design decisions which maybe made sense ten years ago but not anymore, I'd rather have an "unstable" API.

        So basically, if you want to provide closed drivers - f

    • Re:Download Size (Score:5, Informative)

      by Quixote ( 154172 ) on Saturday August 14, 2004 @08:52AM (#9966871) Homepage Journal
      If you have the previous version, you can just download the patch; it is 3691743 bytes (about 3.5MB).
    • Most distros come with some sort of vanilla or patched kernel tree and you can patch those to the latest kernel revision which requires a much smaller download (for example the bzip2'd patch for 2.6.7 -> 2.6.8 is only 3.5M) But you do have a point. It might be nice to just release a make config/menuconfig style kernel configurator which, after you selected your system specific options and drivers, downloads only those specific parts of the kernel that you selected. Maybe some menuconfig style sort of k

    • Re:Download Size (Score:3, Informative)

      by GammaTau ( 636807 )

      I think Linux is a great kernel, but a 42 MB download is really a bit too much for my liking.

      That's the size of the .tar.gz version. Bzip2 compresses a lot better. The .tar.bz2 version at kernel.org is about 9 MB smaller.

    • Re:Download Size (Score:5, Insightful)

      by Spoing ( 152917 ) on Saturday August 14, 2004 @09:14AM (#9966956) Homepage
      1. I think Linux is a great kernel, but a 42 MB download is really a bit too much for my liking.

      [ suggestions for reducing the source update snipped ]

      The upgrade patch from 2.6.7 to 2.6.8 is under 4MB and can be found right along with the complete source here. [kernel.org]

      Splitting the kernel source into parts would be a logistical problem...and I'd rather the developers not be bothered with it. If you want source, and you want small file sizes, using a diff to patch a previous release is a reasonable compromise. There are plenty of comments on the web on how to apply these patches, so being a developer isn't even necessary.

      Most of the suggestions you have would be appropriate for a binary release, though binary kernel packages are much smaller anyway so much of the benifit there is also lost.

      That said, there could be improvements on the package updates for just about every package ... I don't know any that do atomic updates (ex: MD5 sums of the files and fetch only the ones that differ...or apply a patch to make the files match.). That would be quite handy for mass deployment of files over a LAN to cut down network traffic; push out the update details to the clients, have the local systems check if they need a specific file, have the local systems report back what they need or if they are already OK. Not ideal for every situation, though it could be benificial. I wouldn't be surprised if the Tivo updates are handled like this.

    • Re:Download Size (Score:1, Redundant)

      by gl4ss ( 559668 )
      how about if you really think any of those features are worth s*it you do it?

      they're not deemed worthwhile, hence nobody is doing that.

      enermous complexity...

    • Isn't Linux under some source control system now?

      So you should be able to sync your local sources with a public repository at any time you want and don't havve to download huge tar files or fiddle with patches.

    • Rsync? (Score:2, Interesting)

      by msh104 ( 620136 )
      the kernel seems to have a rsync mirror. I haven't tried it yet, but that way you would be able to download the kernel in cvs style by only downloading what you need. this ofcourse only has a adventage when you download new kernel versions all the time, but most people that download from kernel.org seem to do just that. I also like the all in one package. this way I don't have bother 'bout searching for supported hardware. if it ain't in linus tree, it's not worth it for me.

      • Re:Rsync? (Score:2, Interesting)

        by johnw ( 3725 )
        Nice idea, but I haven't yet seen a kernel mirror which carries the source in plain .tar format. It's always .tar.gz and .tar.bz2.

        A specific rsync mirror which carried it as just .tar would allow what you say to work, and it should work very well. Very little management overhead to set up too (particularly compared with trying to make the source tree modular).

        John
    • I think Linux is a great kernel, but a 42 MB download is really a bit too much for my liking.

      You should get bzip2 [redhat.com]. Cuts down the filesize to about 34 MB...

    • Re:Download Size (Score:3, Insightful)

      by tjrw ( 22407 )
      This has come up numerous times before on lkml and been debated to death. Search the archives if you want to see the arguments. Executive summary is, it isn't going to happen. If you're into kernel-hacking, or just following the latest updates, I would hope that you already have 2.6.7, in which case the patch is not particularly large. There's no need to download the whole thing every time.

    • It probably wouldn't be hard to produce scripts which would extract the configuration and build system from a linux distribution, so that you could distribute only that part initially, and get other files as needed. (Actually, you'd probably do it by the directory to keep things simple)

      On the other hand, you'd have to download multiple things in order to build your kernel, and you'd have to download parts after you'd configured. The kernel site would have to either have a lot of little tar files (which wou
    • I think Linux is a great kernel, but a 42 MB download is really a bit too much for my liking.

      A suggestion: you don't have to download anything. Your distro provides you with a kernel. use it. be happy.
  • From the changelog:

    From: Guennadi Liakhovetski g.liakhovetski@gmx.de
    Update the driver to use the new pci, scsi and module interfaces.

  • Most of the new options seem pretty normal, but can someone explain this "Default codepage for FAT" option? Cheers...
    • Just a stab but I was using a FAT filesystem for mass exchange of data between Linux and WinXP apps on the same machine. I found it quite annoying that there was something screwing with the upper vs. lower case on my filenames. Windows would write upper and linux would see it as lower. I'm hoping that you are the bearer of good news.....

      • Re:Codepage for FAT (Score:2, Informative)

        by Anonymous Coward

        Windows would write upper and linux would see it as lower. I'm hoping that you are the bearer of good news.....

        Under MS Windows, when you write a filename that conforms into 8.3 format and consists of all upper-case characters, only basic FAT entry will be written, not the VFAT entry.

        When you list the name of such file under linux, two things happen:

        1. VFAT driver only finds 8.3 name and will ignore the case of the characters
        2. as a norm (as historicaly, under *IX platforms most of the names are lower case
        • Your explaination fits the observed behavior. I dodged using symlinks out of a ext2 fs and carried on.

          However, understanding the cause does not necessarily equate to a solution. Like most Win apps, I cannot change it much. In this case, I cannot force it to use different names. Therefore it remains a problem should I need to do that particular operation again. I would like to have an option in mounting the FAT fs under Linux. Perhaps with your info I might find one.

          Thanks

    • Re:Codepage for FAT (Score:5, Informative)

      by Anonymous Coward on Saturday August 14, 2004 @09:28AM (#9967010)

      Most of the new options seem pretty normal, but can someone explain this "Default codepage for FAT" option? Cheers...

      This one goes to the stone age of DOS... Under DOS you could write file names that included ASCII characters with codes above 127. When first localized versions of DOS appeared, you bumped into what most people still don't understand today: under your local codepage (here we used to use CP 850, US one was 437) different codes represent different characters. Since we're talking about times when Unicode was still just a thought in some lonesome head, the characters you typed for filename appeared differently when DIRed under different codepage settings.

      Now enter 21st century... most of the charcter strings are already in one or the other UCS/Unicode format. This means that we're mostly talking about Unicode character "small e with caron", not the character 152 in CP 850. The problem you have with this is to guess what was the original codepage used to write the text file or filename so you can convert from Unicode to local CP and back.

      In MS Windows this is solved by defining default system codepage. If you're a long-time MS user, then you have basicaly went all the way from the end of '80s to now using default codepages for your particular region and all this is transparent to you.

      When you come to the Linux however, what particular application considers to be your codepage has no bearing to what the kernel wants to know about you. Kernel simply doesn't do codepages. Glibc can do them, but hardware as a rule doesn't care whether it runs in China or in US. Thus, for this particular FAT problem, you have to explain the kernel module what do you consider to be a default codepage so it knows how to convert filenames from disk to userland and back.

      In short: if you live in a region that considers ISO-8859-1 to be a default, then 437 is for you, if you live somewhere else, you probably already know all this, and you have only read it this far to see if you could correct some of more glaring mistakes I have made.

      Anonymous Cowards Unite

      • In short: if you live in a region that considers ISO-8859-1 to be a default, then 437 is for you, if you live somewhere else, you probably already know all this, and you have only read it this far to see if you could correct some of more glaring mistakes I have made.

        I believe you mean 850, the international european codepage. 437 is US-only, and corresponds more to ASCII than Latin-1.

  • 2.6.8 has NFS3 problems (Score:3, Informative)

    by el-raza ( 799716 ) on Saturday August 14, 2004 @09:11AM (#9966945)
    people who use NFS should wait for 2.6.8.1: 2.6.8 oopses with nfs [iu.edu]
  • Since I'm running the 2.4 kernel without any problems, and I have had massive issues previously with a kernel update. As it is, I know I'm using a really old version of the 2.4 kernel, but I can't justify the risk in updating. I don't want to have to reformat my Linux system again.

    • Re:Not updating (Score:5, Informative)

      by Slack3r78 ( 596506 ) on Saturday August 14, 2004 @10:13AM (#9967182) Homepage
      A couple of things here. Sticking with 2.4 is reasonable, but running an old version of 2.4 is a bad idea IMO. There are enough security vulns fixed every few releases that I'd seriously consider patching, if I were you. Know how we all pick on Windows kiddes for not updating? Linux doesn't give you a free pass to run unsecure versions either.

      Second, even if a particular kernel has issues on your machine, there is *no* reason you would have to reformat. Simply create a new entry in your bootloader and leave the old Kernel as an option. That way if you forget to compile something you need in, you still have the old kernel to fall back on. This is the reason why when my laptop boots up, GRUB offers me a choice of the stock Slackware 2.4 kernel, and 4 or 5 2.6 revisions. HD space is cheap and kernel binaries are small - there's no reason not to.
      • Well, when I tried updating the last time, I had a major system failure that corrupted everything. It was a massive disaster. I should say that I do patch every now and then, but updating to 2.6 is totally out of the question.
        • It corrupted everything? What do you mean by that?
          Would the machine not boot up (A)? Would it boot up, but all your data was gone (B)? Would it not boot up, and when you tried to roll back the update you found all your data was gone (C)?

          If (A), you should probably keep an older kernel around in you bootloader so you can roll back if the kernel didn't work. Whenever I roll my own kernel it usually takes me a couple tries before I get one that boots (I usually forget something simple like Ext3 filesystem sup
      • Is there a simple way to know which kernel upgrades include security patches, and which do not? The changelogs are huge, it would be great if someone did the work and shared it with all.
        • Unfortunately I think it's just too complicated to take changes to the kernel piecemeal. In effect you'd be creating your own version, which might have bugs of its own.

          Staying within the same series (i.e. 2.4) "shouldn't" break things. We all know that's occasionally false, but I think the best you can do is file a bug report, then stay with the older version until a newer version fixes your problem.

          Unless you have untrusted users running shell accounts on your machine, you usually don't need to upgra

    • Re:Not updating (Score:4, Informative)

      by MarcQuadra ( 129430 ) * on Saturday August 14, 2004 @12:21PM (#9967932)
      I had a manager a few years ago who got burned bad by NT service pack 5. He wouldn't let us install anything newer than SP5 in the lab. Terrible things ended up happening one day when a worm broke out and we couldn't even patch the systems because it was against policy.

      I've been through bad kernel upgrades too, but you should be fine if you follow procedure and stay conservative:

      1. get latest kernel in your tree (2.4.27 for you). It's been out a few days with no major issues. Unpack it to /usr/src/linux-2.4.27

      2. Find your current .config (/usr/src/linux/.config ?) and copy it to /usr/src/linux-2.4.27/.config

      3. cd to linux-2.4.27/ do a 'make oldconfig'. You may want to view your current .config in another window to cross-reference. You'll only have to answer questions for changes since your old config.

      4. make -j2 bzImage && make -j2 modules

      5. install the files. all this is well documented from here on, so I'll stop this, but make sure to keep your current config in your bootloader in case this kernel burns you.

  • Logitech MX700 mouse (Score:1, Interesting)

    by cs02rm0 ( 654673 )
    still isn't working after anything newer that I've tried than 2.6.7-rc2. :(
  • 2, 6, 8, who do we appreciate? Linus! Linus!
  • Anyone know if the issues with VIA chipsets, ACPI and APIC were resolved between 2.6.3 and 2.6.8?

    Running a K7T266A, I had do disable ACPI, APIC, and Local APIC, or I'd get hangups and USB wouldn't work.

    • Maybe, I haven't tried it, but this is in the 2.6.8 changelog:

      [PATCH] bug in V-link handling (arch/i386/pci/irq.c)

      Via southbridges use register 0x3c of the on-board devices (USB and AC97) to control interrupt routing for those. In drivers/pci/quirks.c we set it correctly (dev->irq & 15). However, in pirq_enable_irq() where the second half of that stuff lives, we forget to apply the mask.

      That's what causes problems with ioapic on via motherboards in 2.6.
      One-liner below ACKed by Alan, verified on

Slashdot Top Deals

"An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it will also make better soup." - H.L. Mencken

Close