Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software Linux

Linux Kernel 2.6.6 Released 350

Posted by Hemos from the let's-do-the-kernel-build-again dept.
maradong writes "The new Linux Kernel 2.6.6 has been released just 2 hours ago. The Patch from version 2.6.5 to 2.6.6, which can be downloaded on kernel.org measures 2.4MiB and the Changelog can be found at the known place."
This discussion has been archived. No new comments can be posted.

Linux Kernel 2.6.6 Released More

Linux Kernel 2.6.6 Released

Comments Filter:

  • Breaks Nvidia Module (Score:5, Informative)

    by fire-eyes ( 522894 ) on Monday May 10, 2004 @07:02AM (#9105316) Homepage
    Note that this breaks the loading of Nvidia modules.

    Rather annoying since Nvidia knew this issue was coming.

    The fix is to back a patch out, but it's a bad idea.

    Stay at 2.6.5 if you use Nvidias drivers, for now.

    • Re:Breaks Nvidia Module (Score:2, Interesting)

      by jmoen ( 169557 )
      Works fine for me, straight from the source:
      ...

      Module Size Used by
      nvidia 2074600 12
      ...

      Linux duplo 2.6.6 #1 Mon May 10 11:01:29 CEST 2004 i686 GNU/Linux

    • Re:Breaks Nvidia Module (Score:4, Informative)

      by poing ( 85452 ) on Monday May 10, 2004 @07:21AM (#9105432)
      I am running 2.6.6 now and nvidia-installer from NVIDIA-Linux-x86-1.0-5336-pkg1 compiled a module for me without a hitch, just like on previous 2.6 kernels. No problems whatsoever.

    • Re:Breaks Nvidia Module (NOT COMPLETELY TRUE!) (Score:5, Informative)

      by Turmio ( 29215 ) on Monday May 10, 2004 @07:34AM (#9105507) Homepage
      It'll only break if you choose the new CONFIG_4KSTACKS option (use 4Kb for kernel stacks instead of 8Kb under the Kernel hacking menu of menuconfig). Leave that option unchecked and it should work just fine (I'm using 2.6.6-rc3-mm1 right now with NVIDIA's driver).
    • I wish that I could just patch the bits of the kernel that are important to me, and not the whole lot in one go.

      I would be far more lightly to test betas if I could download driver and filing system updates that relate to me instead of the whole kernel which may have new less stable featuers, my build times would be lower and my system would be more stable.

      It would also make it easier to upgrade everything except the broken Nvidia bits....

      Oh, I wish i could just patch /kernel/drivers/net/eci100 and nothi

    • FIXES nForce2 apic, finally (Score:5, Informative)

      by dpilot ( 134227 ) on Monday May 10, 2004 @07:35AM (#9105514) Homepage Journal
      Last week someone from nVidia finally stepped up to the plate on lkml and told us all the real problem with the apic hangs. They'd told the BIOS writers long ago, but from what I can tell, only Shuttle had done anything about it. So they finally released the same info to the Linux community.

      Hours after the information was released, the first patch followed. A little feedback and tweaking, and it's into the mainline kernel in less than a week. Kudos to Ross Dickson, et al, for all the work they'd done trying to fix this problem, prior to the official informatino release.

      Does anyone know if the patch for either forceDeth or the 3com 2nd adapter on some nForce2 boards is in the mainline kernel, yet?
      • Does anyone know if the patch for either forceDeth or the 3com 2nd adapter on some nForce2 boards is in the mainline kernel, yet?

        I don't know about the 3com one, but I've been using the forceDeth driver since 2.6.4 with absolutely no problems.

    • Re:Breaks Nvidia Module (Score:5, Informative)

      by Mr Smidge ( 668120 ) on Monday May 10, 2004 @07:40AM (#9105565) Homepage
      From the changelog, for those who are interested but too lazy to find it themselves:

      [PATCH] ia32: 4Kb stacks (and irqstacks) patch

      From: Arjan van de Ven

      Below is a patch to enable 4Kb stacks for x86. The goal of this is to

      1) Reduce footprint per thread so that systems can run many more threads (for the java people)

      2) Reduce the pressure on the VM for order > 0 allocations. We see real life workloads (granted with 2.4 but the fundamental fragmentation issue isn't solved in 2.6 and isn't solvable in theory) where this can be a problem.

      In addition order > 0 allocations can make the VM "stutter" and give more latency due to having to do much much more work trying to defragment

      The first 2 bits of the patch actually affect compiler options in a generic way: I propose to disable the -funit-at-a-time feature from gcc. With this enabled (and it's default with -O2), gcc will very agressively inline functions, which is nice and all for userspace, but for the kernel this makes us suffer a gcc deficiency more: gcc is extremely bad at sharing stackslots, for example a situation like this:

      if (some_condition)
      function_A();
      else
      function_B();

      with -funit-at-a-time, both function_A() and _B() might get inlined, however the stack usage of both functions of the parent function grows the stack usage of both functions COMBINED instead of the maximum of the two. Even with the normal 8Kb stacks this is a danger since we see some functions grow 3Kb to 4Kb of stack use this way. With 4Kb stacks, 4Kb of stack usage growth obviously is deadly ;-( but even with 8Kb stacks it's pure lottery.
      Disabling -funit-at-a-time also exposes another thing in the -mm tree; the attribute always_inline is considered harmful by gcc folks in that when gcc makes a decision to NOT inline a function marked this way, it throws an error. Disabling -funit-at-a-time disables some of the agressive inlining (eg of large functions that come later in the .c file) so this would make your tree not compile.

      The 4k stackness of the kernel is included in modversions, so people don't load 4k-stack modules into 8k-stack kernels.

      At present 4k stacks are selectable in config. When the feature has settled in we should remove the 8k option. This will break the nvidia modules. But Fedora uses 4k stacks so a new nvidia driver is expected soon.

  • How is this different than updating Windows? (Score:3, Interesting)

    by VashSpaceCowboy ( 742062 ) on Monday May 10, 2004 @07:04AM (#9105331)
    I'm not trolling here, it is just my knowledge of Linux is limited. It seems like updates to the kernel get released all the time. How is this way of fixing bugs any different than the microsoft update? Vash

    • Keyword: Improvement (Score:5, Informative)

      by trezor ( 555230 ) on Monday May 10, 2004 @07:10AM (#9105370) Homepage

      This is not as much bugfixing as it is improving the kernel.

      Like writing better code, better memoryhandling, adding new features, improved hardwaresupport and the like.

      And unlike Windows Update, you don't have to update the kernel if you don't want to. Very little software do require specific kernel-versions, as opposed to Microsoft where almost everything seems to have kernel tie-ins.

      Hope this answers your question.

      • Re:Keyword: Improvement (Score:2, Informative)

        by Anonymous Coward
        And unlike Windows Update, you don't have to update the kernel if you don't want to. Very little software do require specific kernel-versions, as opposed to Microsoft where almost everything seems to have kernel tie-ins.

        Ahem? Almost everything on windows hooks NTDLL functions that are specific to each ntoskrnl release? I think you need to check your facts again. Only drivers would be hooking kernel functions, which requires the program to execute in ring0. Even then, the NTDLL exports are pretty much iden

    • Re:How is this different than updating Windows? (Score:5, Informative)

      by cozziewozzie ( 344246 ) on Monday May 10, 2004 @07:11AM (#9105378)
      Every piece of software gets updates as bugs get squashed and new features added. The gripe with windows is that the updates don't come as often and they often break other things, so your system can be vulnerable for long periods of time. Also, Microsoft has been known to ignore critical errors, while linux problems generally get fixed very quickly.

      The big difference is in the development process, so you can see what exactly is changing, you can fix things that break your system (for example, the nvidia problem somebody mentioned already) and you can choose between different kernels (more feature-rich, more stable, or more performance-oriented) maintained by different people. You don't get this freedom with closed-source software.
    • For one, it's only the source that's released, and it's not directly connected
      to any end user product. Ordinary users need not care, they should update and install a new kernel whenever it's released by their linux distribution vendor. Which isn't all that diffrent from "Windows Update".
      The kernel.org releases are not just bugfixes, it's heaps of new features
      as well usually.
    • The difference is that when a bug is found in the Linux kernel, its usually patched within a couple of weeks or so.

      When a bug is found in Windows, it can take months for a patch to be released...if ever.

      Anybody with an intelligence level higher than a rock will tell you there is no such thing as a bug-free OS. The difference is in how fast those bugs are fixed.
    • The Linux kernel is cool and all that stuff, Windows isn't.
    • Long story:
      this is just the kernel + drivers/modules, distributions (RH/Suse/Mandrake/Debian) use this as part of there distribution just like any other piece of software (GIMP/KDE/whatever).

      So if they bring out a new version of there distribution, you could compare that with an update/upgrade from Microsoft (they all package it for the 'end-user').

      the Linux kernel is not for most end-users, only for developers (who might need something specific) or system-administrators that need more control over exactl

    • Re:How is this different than updating Windows? (Score:5, Informative)

      by molarmass192 ( 608071 ) on Monday May 10, 2004 @07:22AM (#9105436) Homepage Journal
      If you're a new user or an end user, you shouldn't concern yourself with vanilla kernel updates. Your distro should provide hot patches like MS Update on some kind of a regular basis. As for how different that MS Update that is, it's not, a code fix is a code fix, regardless of your platform. There's nothing really wrong with this since MS Update is actually a decent patching facility.
    • It means that all those hard working folks who just prepared May 1 release distros now have to go back to the labs and retest all their packages again for compatability if they want to keep up with the Joneses. And it can be a HUGE Pain! (LiveCDs especially with all those pre-installed packages...)
    • It's done in the open, and anyone capable can play.

  • It seems a bit risky (Score:5, Interesting)

    by Anonymous Coward on Monday May 10, 2004 @07:05AM (#9105338)
    A lot of changes went in this release, and from what I read on several mailing lists, there are some regressions. For example it seems the IDE cache flush at shutdown fix is causing trouble for some people. I think I will wait for the next release...

  • Laptop-mode (Score:5, Informative)

    by Zarhan ( 415465 ) on Monday May 10, 2004 @07:05AM (#9105339)
    Check out the now merged laptop mode [xs4all.nl]. Allows you to really save that battery. It is also good on my home server that uses hostap - there is not too much to write on disk, so I'll set the timeout to something like once a week...

    A definite must for laptop users that want a little more operating hours from their batteries.
    • Laptop mode definitely helps, but as a side effect DMA is disabled for laptops now (well, atleast on my Acer TravelMate 274), which hampers startup performance a little.

      • Re:Laptop-mode (Score:3, Informative)

        by Handyman ( 97520 ) *
        Laptop mode does nothing that could cause this. This problem is probably related to other changes in 2.6.6. If you want to use laptop mode without the DMA problems that are apparently present in 2.6.6, use 2.6.5 with the laptop mode patch from my laptop mode [xs4all.nl] web page.

        -- Bart Samwel
      • Laptop mode definitely helps, but as a side effect DMA is disabled for laptops now (well, atleast on my Acer TravelMate 274), which hampers startup performance a little.

        Eh? How do the IDE bus and hard drive know they're on a laptop? Are you sure something weird didn't happen with hdparm?

  • BTTV question (Score:4, Interesting)

    by Rosco P. Coltrane ( 209368 ) on Monday May 10, 2004 @07:07AM (#9105355)
    Does anybody know if the bttv video card issue, the one that would freeze the machine when capturing from a bttv card under heavy system load, is resolved?

    I'm not lazy asking about this here, it's just that I looked everywhere in the changelogs and I can't see anything about it, yet the problem is known [iu.edu]. Perhaps the problem went away as another was fixed? Anybody has any experience on this?
    • Oops, wrong link. That was an old bttv problem. But I can't find the link to the 2.6 one now. Duh me...
    • How bizarre, asking if a problem in 2.2.12 is fixed in 2.6.6!

      Although I think I know what you're talking about, I had a machine (running 2.4.18 I think) which crashed regularly with bttv, but ran like a dream without it. Eventually I moved the card into another machine (same kernel, slower but better quality hardware) and there were no problems.

    • Re:BTTV question (Score:3, Informative)

      by anpe ( 217106 )
      Although some frames get skipped from time to time (under heavy load), my bt848 is doing fine since the early 2.6.0-testX series...

  • argh (Score:2, Interesting)

    by Anonymous Coward
    Still nothing in the changelog indicating my the wheel on my mouse won't work :(

    I'm assuming it's entirely a kernel issue as cat /dev/input/mouse0 or whatever produces nothing when I play with the wheel, but it does for everything else.

    • Re:argh (Score:4, Informative)

      by pacman on prozac ( 448607 ) on Monday May 10, 2004 @07:40AM (#9105564)
      Aha, mine also stopped working in 2.6.6-rcX.

      I had to set the type as ExplorerPS/2 in XF86Config (was IMPS/2 before).

      Although, you should see something when you cat /dev/input/mouse0 and hit the wheel, maybe you're missing some modules. Check you have: ohci_hcd, ehci_hcd, uhci_hcd, usbmouse and usbhid.

  • SIS964 SATA (Score:3, Interesting)

    by madhippy ( 525384 ) on Monday May 10, 2004 @07:08AM (#9105360)
    [libata] Add driver for SiS 964/180 SATA.

    [libata sata_sis] minor cleanups

    Anyone using sis964/sata? is it working ok? any major distros you can recommend? (stuck with WinXPPro on my new machine....)
  • and so far it looks prett=20 ]} $}1}&..}=3Dr}'}"}[NO CARRIER]

  • Kernel Acceleration (Score:3, Interesting)

    by Skraut ( 545247 ) on Monday May 10, 2004 @07:49AM (#9105646) Journal
    Is it just me or is the pace of kernel releases accelerating dramatically. Just a quick look at the number, 2.6.6 seems to indicate that we are now 3/5 through the lifespan of the 2.6 kernel.

    Granted, I know that is not the case, but 2.6.x is not even 6 months old ( 2.6.0 released December 18th, 2003) at this rate of release are we looking at 2.8 in September? This just seems crazy to me. I thought that's what the "odd" numbered kernels were for, testing. At this current rate of release it sure feels like the supposed "stable" kernels are the ones being tested on.

    This isn't meant to be a troll or a flame just an observation. Many of the distros have finally gotten around 2.6, but it sure seems like the kernel devs have given the distro devs a very rapid moving target to hit. I still see all to often recomendations here and other places telling people to use 2.4x for "mission critical" use. Why?


    Why is 2.6 not as reliable as 2.4 was?
    Why are people in this thread commenting about all the things 2.6.6 breaks?
    Why does an even kernel need to break *ANYTHING* isn't that what dev kernels are for?

    I love to see progress as much as anyone, heck, I run Gentoo. I just wonder if the Kernel needs to be treated with a bit more care. Would you buy a car from an auto maker, who every month changed the engine in their car?

    • Re:Kernel Acceleration (Score:5, Informative)

      by ZaMoose ( 24734 ) on Monday May 10, 2004 @08:06AM (#9105774)
      Errrm, the kernel numbering scheme doesn't work on a "Oh crap, we hit x.y.9, next rev is x.y+1.0!" scheme. The third number has no ceiling; theoretically, we could see 2.6.159, if there was any reason to continue the 2.6.x kernel out that far.

      2.4 is hovering in the low 20's as far as minor rev. number at this point.

    • Re:Kernel Acceleration (Score:4, Insightful)

      by Ann Elk ( 668880 ) on Monday May 10, 2004 @08:16AM (#9105862)

      3/5 through the lifespan of the 2.6 kernel? WTF?? The kernel after 2.6.9 will be 2.6.10, not 2.7.0. For example, the current 2.4 kernel is 2.4.26...

      2.6.0 is not as reliable as 2.4.26 because the latter has had 26 updates to get things "right". This is just the way things work in kernel development.

      The 2.6 series has broken a few things, largely because:

      • There were a lot of major, architectural changes between 2.4 and 2.6. It probably should have been called 3.0.
      • A few kernel features that have been marked as "deprecated" in previous kernels have now been officially removed. This should have surprised no one. The kernel team is neither arbitrary nor capricious (for the most part :-).
      • The kernel is, obviously, a single point of failure. If a new kernel is deployed on 1,000,000 machines and only 0.1% have problems, that's still 1,000 people complaining on the mailing lists.

      Would I run 2.6 on a mission-critical highly-buzzword-enabled enterprise server? Not yet. Do I run it on my desktop? Abso-fucking-lutely.

    • New 2.4 versions appeared quite quickly as well in the early days. See the dates in the file listing [kernel.org]. It just needs some time to mature...

      I have to say that 2.6.5 seems to be quite okay on my home server already. I wouldn't even think about running it on a colocated server (ie one with an unreachable reset-button and a certain level of importance) though. Just because of my experiences with other early kernels...

    • Re:Kernel Acceleration (Score:2, Insightful)

      by csirac ( 574795 )
      I think the early part of an even numbered release is always prone to bugs/instability/rapid activity. 2.4 had some major issues in the beginning too, I think i2o was broken around 2.4.10, along with code rewrites of seemingly important areas. I'm not sure if I ever got to use power managment stuff properly in 2.4.

      Just as with 2.2 -> 2.4, I think people will stick with 2.4:
      a) as long as possible (if it isn't broken, don't fix it)
      b) until 2.6 is "more stable".
      c) as soon as they could be bothered upgradi

    • Re:Kernel Acceleration (Score:3, Informative)

      by smcv ( 529383 )
      Is it just me or is the pace of kernel releases accelerating dramatically. Just a quick look at the number, 2.6.6 seems to indicate that we are now 3/5 through the lifespan of the 2.6 kernel.

      Version numbers are not usually decimal, they're usually a sequence of arbitrary dot-separated integers - don't think of decimal fractions, think of books with chapter 1, section 1.2, subsection 1.2.34, paragraph 1.2.34.5 (this scheme is common in maths and computer science textbooks).

      Linux 2.4 is up to 2.4.26, 2.2 i

    • Re:Kernel Acceleration (Score:3, Interesting)

      by Lxy ( 80823 )
      IIRC, 2.4 saw 12 or 13 revisions in its first year. It wasn't until 2.4.16 that I even started using it, because of all the bugs. Right around 2.4.18 it got my OK and I stopped using 2.2 kernels. Now it's up to 2.4.26, only 8 changes in over a year.

      2.6 is actually a bit slower in its release cycle. I've also found the 2.5 stuff to be more stable than the 2.3 codebase. I'm guessing I'll be using 2.6 regularly in the coming months, probably around 2.6.8.

  • omm (Score:4, Funny)

    by mattyrobinson69 ( 751521 ) on Monday May 10, 2004 @07:51AM (#9105667)
    Youve Slashdotted Kernel.org!

    You Bastards!

  • Mirror. (Score:5, Informative)

    by idiot900 ( 166952 ) * on Monday May 10, 2004 @07:55AM (#9105688)
    kernel.org seems slashdotted from here. Good job direct-linking to it in the story.

    Mirror to the rescue!

    http://wuarchive.wustl.edu/pub/linux/kernel/v2.6 [wustl.edu]

  • 2.6.6 seems to boot faster. (Score:3, Interesting)

    by tim_retout ( 716233 ) on Monday May 10, 2004 @08:05AM (#9105760) Homepage Journal

    I just downloaded the patch and am successfully running 2.6.6. :-)

    Is it me or was the boot time considerably faster than before? Almost blinked and missed it. Anyone else found that?

    Now I just have to clean out init.d.

  • Where are the English release notes? (Score:3, Insightful)

    by gosand ( 234100 ) on Monday May 10, 2004 @08:21AM (#9105891)
    Why, oh why, can't there be an official release of the kernel that describes the changes in plain language instead of coder-speak? Look, I know what kind of people it takes to hack the kernel - brilliant people. They think like coders. But when new versions of the kernel are released, why can't there be a summary of what is new/changed? In simple terms.

    Not everyone who uses Linux is a kernel hacker, especially nowadays. And yes, there are sites out there that give rundowns of what has changed. But wouldn't it be nice to have an *official* release statement that outlines the changes made? It seems logical to me that the people managing the changes would be able to articulate this the best. I think it would go a long way in making Linux seem a bit more mature.

  • So relaxen und watchen das blinkenlights (Score:4, Funny)

    by Spoing ( 152917 ) on Monday May 10, 2004 @08:34AM (#9106002) Homepage
    Was ist das blinkenlights? [blinkenlights.com] Ist NEU! 2.6.6!
    1. david dash b at pacbell net

      [PATCH] USB: usbcore blinkenlights

      The per-port LEDs on the most USB 2.0 hubs are programmable. And the USB spec describes some ways to use them, blinking to alert users about hardware (amber) or software (green) problems.

      This patch is the infrastructure for that blinking. And if you should happen to "modprobe usbcore blinkenlights", the LEDs will cycle through all the ports ... which is not a USB-standard mode, but it can certainly handy be handy as a system heartbeat visible across the room.

    Das ist goot, ja!

  • Kernel numbering (Score:4, Interesting)

    by 1000101 ( 584896 ) on Monday May 10, 2004 @08:43AM (#9106087)
    Just out of curiosity, what's it going to take to get to kernel version 3.0? Honestly, what changes, additions, etc have to be incorporated until they call it Kernel 3.0?

  • Anyone catch this changelog entry? (Score:3, Funny)

    by Anonymous Cowabunga ( 738559 ) on Monday May 10, 2004 @12:08PM (#9108135)
    (dmcbride@sco.com)
    Added proprietary Unix System V lines of code

Slashdot Top Deals

Adding features does not necessarily increase functionality -- it just makes the manuals thicker.

Close