Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Linux 2.5.2 Kernel Released 234

Posted by Hemos from the go-and-compile dept.
valdis writes "Amazing.. it's been out over 3 hours and not discussed to death. Well, maybe there's not as many bleeding-edge crazies out there. But if there are, here's what's new. You can get it at the usual place, but please use the mirrors if you can."
This discussion has been archived. No new comments can be posted.

Linux 2.5.2 Kernel Released More

Linux 2.5.2 Kernel Released

Comments Filter:
  • Well, 2.5 is coming along, lets help them out and test it.

  • Bah (Score:2, Funny)

    by MjDascombe ( 549226 )
    No 2.6.x yet? :p (only kidding - well done everyone)

  • USB (Score:5, Interesting)

    by ciryon ( 218518 ) on Tuesday January 15, 2002 @08:02AM (#2841347) Journal
    USB update (including initial 2.0 support)

    Sounds rather interesting. I've had some issues with my Rio 800 MP3 player with many 2.4 kernels, perhaps it's more stable now? Also great that the kernel guys are working on 2.0 support.

    Ciryon

  • So... (Score:4, Funny)

    by dbolger ( 161340 ) on Tuesday January 15, 2002 @08:02AM (#2841349) Homepage
    ...who's up for setting up a tent outside RedHat HQ and waiting for the first 2.5.3 release? ;)

  • Mirrors (Score:5, Informative)

    by Rentar ( 168939 ) on Tuesday January 15, 2002 @08:02AM (#2841351)
    Apart from the entire 'slashdot is not freshmeat'-discussion I'd like to note, that maybe slashdot should not mention the URL to the kernel archive, but only the URL for the mirrors-list. I'm sure everyone able to compile and use a 2.5.x kernel is able to find the correct download directory, should he be confronted with a mirror list.
    • ...And look at the bright side if users can't figure mirror lists out. It's a slashdot effect 'Narrowly averted'.

      Josh Crawley
    • Whaaaaattttt.......don't you think that Trasmeta WANTS their Servers to go down and their Bandwidth bill to sky Rocket? :-)

    • Re:Mirrors (Score:2, Interesting)

      by Ami Ganguli ( 921 )

      Hmm. Considering their bandwith utilization right now is only 40Mb/s (out of 100) I don't think it's a huge issue. And this while being Slashdotted too.

      I wish I had that kind of bandwidth :-).

  • Why? (Score:1, Interesting)

    by neroz ( 449747 )
    Why is this being announced here? This is the development kernel series. MANY releases are to come, and I really hope that the announcements stop. These kernels are not intended for end users, and you may end up being the reason some newbie installs the kernel and has his drive fsck it self into oblivion. The 2.5 series is going to last a long time because of the radical changes planned, so really, stop announcing them.
    • it's not like it's a new practice, I remember seeing posts mentioning 2.1.127 or 2.1.83 back in the day...

      Slashdot is whatever they want to make it. It's not your site, you don't select the stories, if you don't like it, go to kuro5hin where you do select the stories.

      Or something.

      Bah.

      -gleam
    • Its new, its for nerds and what's more important, it makes for interesting discussion.

      The idea here isn't that we all don't know that it's been released, but we do want to know what other /.ers think about it.

      If a thread doesn't interest you, by all means don't read it - what's the point of whining?

  • Or maybe... (Score:5, Interesting)

    by SilentChris ( 452960 ) on Tuesday January 15, 2002 @08:21AM (#2841417) Homepage
    "Well, maybe there's not as many bleeding-edge crazies out there."

    Or maybe most of us are at work and are working on (relatively) stable workstations that we can't tinker with. I'm not a kernel hacker myself (I wait until a distro comes out with a new stable kernel and all the trimmings) but I can imagine that kernel traffic probably peaks after business hours.

    • Re:Or maybe... (Score:2, Flamebait)

      by gus goose ( 306978 )
      I do not usually jump on this band-wagon ... but ...

      Not everybody is at work, and although the US has a large number of the /. population, more than half the Linux developers are non-US. Regardless, most non-US probably have their own local mirror.

      My point is that you should be a little less US centric when contemplating something like Linux.

      Same old same old ... moderate as appropriate.

      gus
    • Actually I am downloading it right now (I am at work) to test out on a development box I use to try out 'new' things and see how they work against current releases if it offers a major improvement than I know that when it gets to a stable version I can/should use it and since I have used the development kernels up to that point i have fairly good understanding of it

    • Re:Or maybe... (Score:5, Funny)

      by elefantstn ( 195873 ) on Tuesday January 15, 2002 @10:54AM (#2842236)
      Time for a new job, dude. If recompiling development-branch kernels isn't billable time, you're in the wrong line of work.

  • New Scheduler (Score:2, Informative)

    by Dios ( 83038 )
    While I am not certain, I see the entries for Davide Libenzi, Ingo Molnar on scheduler improvements. Ingo published a huge scheduler update that looks promising, might be worth checking it out if you have a system under high load that tends to be come poky/etc.

    I believe there was some discussion of integrating Ingo's patch with the preemptive patch, should be good for everyone.

    A link to his discussion http://kt.zork.net/kernel-traffic/latest.html#4 [zork.net] on Kernel Traffic.

    • Re:New Scheduler (Score:3, Informative)

      by psamuels ( 64397 )
      Ingo published a huge scheduler update that looks promising, might be worth checking it out if you have a system under high load that tends to become poky/etc.

      Definitely - but you probably won't notice much difference on most machines - his scheduler was intended to address problems particularly with huge systems. A mere 1-CPU or 2-CPU machine isn't going to see the real benefits.

      Which isn't to say the patch is worthless on anything less than 4 CPUs - apparently it beats the old scheduler on all benchmarks. But for most of us, scheduling doesn't take a lot of CPU anyway.

      • On the contrary, I am seeing significant and real benefits on my 1 and 2 CPU machines, especially under high load, everything just runs smoother, every process gets the % of CPU that it deserves. It's not that scheduling takes up a high % of the cpu time, it's that processes aren't scheduled "perfectly" under the current model.

        But you are absolutely correct in that the scheduler improvements will be more apparent and dramatic on 4 and 8-way machines because of the elimination of the global run queue. Each CPU gets its own run queue and processes will only bounce around when other cpu's are idle. We finally have a scheduler that will work on enterprise class machines.

    • Would this new scheduler help me?
      I have a larger linux render farm and the machines are almost always at a +90% cpu utilization. The renderer is one master process and two children processes. All the systems are dual proc. The processes can and will run the system short on memory (1 or 2 GB systems) and sometimes it will hit swap, but this we try hard to avoid.
      Will this new scheduler help such a system. I don't have a ton of processes to run, just a few hefty ones.

      -tim
  • Are those improvements of the scheduler in pre11 and final the O(1) scheduler and the preemptable kernel patches that everyone has been talking about?
    • I would have to say no after a quick glance at the kernel/sched.c

      There are however numerous changes but the mentioned O(1) scheduler additions aren't there yet nor are the preemptible kernel patches. There's still discussion going on what to do with the scheduler roughly regarding interactivity vs thruput.

      (for further reference I suggest to take a glance at the "Re: [2.4.17/18pre] VM and swap - is's really unusable" thread going on in lkml)

    • Re:O(1) Scheduler? (Score:5, Informative)

      by thing12 ( 45050 ) on Tuesday January 15, 2002 @10:38AM (#2842145) Homepage
      I don't think it's in the kernel, but you can get the 'final' patch here (there's one avaiable for the 2.4 series as well):

      http://people.redhat.com/mingo/O(1)-scheduler/ [redhat.com]

      I must say that after using it for a few days, I'm impressed. It totally changes the characteristics of multiprocess servers like Apache and PostgreSQL under high load. For example, I've run ApacheBench against a mod_perl script that queries a pgsql database, in the new scheduler I get a mean response time that is N*1.05*concurrency with a standard deviation of less than 1% of the mean. In the old scheduler I'd get a mean that is N*1.07*concurrency with a sd of up to 75% of the mean. So in other words you get essentially the same throughput with both schedulers (O(1) appears slightly faster in my limited testing). But what's more important is that in the O(1) scheduler everyone is treated equally - they all get served in 1.05*N*concurrency, no more, no less -- while with the old scheduler some requests get a response that's 1*N and others get a response all the way up to 4*N*concurrency.

      IMHO, it's better to give everyone an equal level of service than to randomly favor one group of users over another.

  • I can get back to writing FOLK patches. I should have a FOLK patch out within a week, covering the usual plethora of unadded patches, unheard-of protocols and unsightly drivers. :)
  • From the changelog:
    Jakub Jelinek: fix Linux/x86 confusion about arg passing of "save_v86_state" and "do_signal"

    Seems somehow appropriate. (the confusion, I mean... :) Anyways, what a bunch of prolific hackers. Some of these guys had changes or patches in nearly every pre version.

    The changelog could be a bit more verbose, but otoh, perhaps these kind of descriptions are more thought-inspiring.

  • After I installed Kernel 2.4 w/o any hard drive errors for 6 months using Kernel 2.2, I started receiving Bad CRC errors. I decided that the bleeding edge is not for me and I am going to wait a year before upgrading....
    • After I installed Kernel 2.4 w/o any hard drive errors for 6 months using Kernel 2.2, I started receiving Bad CRC errors.

      Which either means the 2.4 drivers are buggy ... or ... the 2.2 drivers aren't reporting your CRC errors.

      • After I installed Kernel 2.4 w/o any hard drive errors for 6 months using Kernel 2.2, I started receiving Bad CRC errors.

        Which either means the 2.4 drivers are buggy ... or ... the 2.2 drivers aren't reporting your CRC errors.

        It's (probably) the latter; the 2.4 drivers report CRC errors caused during transmission along the IDE cables. You've (probably) always had the problem, now you know about it and should fix it (hint: start by buying some good quality IDE cables...)

        --

  • Updates to OSS drivers (Score:4, Insightful)

    by BlowCat ( 216402 ) on Tuesday January 15, 2002 @08:57AM (#2841581)
    I'm amazed that Pete Zaitcev continues to update YMF PCI sound driver in the middle of discussion about the source layout of ALSA drivers. Nobody doubts that ALSA will be included, the only question is how.
    • Nobody doubts that ALSA will be included, the only question is how.
      Personally as an audiophile, I find the sound reproduction quality of ALSA atrocious when compared to the OSS drivers. On every machine I've tried it on, ranging from laptops to full-blown desktops with the latest Turtle, SB, etc. cards, you can hear a perceptable hiss and overall the volume is lower, even at the same mixer settings. Many dozens of people have reported it, so I am not alone here. I will never use ALSA in a production box, though I think their efforts are noble.
      • Do you have any theories as to what would produce this difference in audio quality (particularly on SB, which is just bog simple -- there really isn't anything that could be different)?

        It could just be linear versus logarithmic mixer settings, but that's not a sound quality issue.

        If that were the case, you would just need to start turning up the volume at the mixer rather than turning up the pot on your headphone cord or your external speaker amp -- both of which will introduce additional "hiss".

        Otherwise, this smacks of "psychosomatic bug" to me.
    • IIRC, the OSS driver for Yamaha is reportedly at least as stable as the ALSA one. So it's possible that the final merge will involve a chunk of this code as the Yamaha driver (i.e., as the part in drivers/sound). Just because the architecture is going to change doesn't mean that all of the drivers will just go away...
  • Somebody should inform Aunt Tillie [theaimsgroup.com] about that ...

    b.

  • It's been a while since I've compiled my own kernel, but one thing has always bugged me.

    It seemed that whenever I wanted to compile a module for some new driver, I would also have to recompile the entire kernel, otherwise the two wouldn't interract correctly (yes, I'm being vague. I think I would get messages about symbols, but it's been a while).

    So, is there a way to compile a single module to run with a kernel that has already been built?

    And what exactly does MODVERSIONS do?

    • yes, and it's easy too.
      after you configure the kernel, changeing it ONLY
      by adding build as module, from something that was not buildt at all. then do a make modules ; make modules_install
      this will make only the modules. nothing else.
    • modversions includes a versionnumber in the symbolnames, so in effect you can only use modules compiled for this kernel, combining kernel and modules with different kernelversions will result in symbols not found. AFAIR this is done by including a header-file in the command-line of the compile-command.

      This mechanism can be switched off in the kernelconfig (something about versioning symbolnames, quite early), or you could compile the module with the correct command-line to do symbol-versioning (AFAIR the version-header-files are made during make dep), if you do a ls -a in some path, where you compiled modules, you'll find hidden files containing the command-line that was used, maybe a 'make xxx.o' will do the job too).
  • Should I encounter any problems moving from 2.4.14 to 2.5.2 on a RH 7.2 box?
  • How is that coming along? From what I recall it was put in 2.4 but it had some goofy bugs. I'd like to use it on our database (Sybase ASE 12.5) and just wondering if they've made any improvements yet.
  • I will stay running the 2.4 series, but this release seems news to me. I understood that some basic i/o has been rewritten during the 2.5.2-pre cycle, and I guess that 2.5 is now stable enough for new features like inclusion of ALSA and CML2. Does anyone have a link to some 2.5 kernel planning?
  • Anyone who is tinkering with the 2.5.x kernel series should be aware that it will break things, because a lot of the underlying interfaces have changed. /proc is no longer laid out in the same way (which breaks vmware, /proc/meminfo is the culpret there, but vmware admittedly should not be using sscanf() to read memory values from /proc), and usbdevfs is called usbfs so as not to be confused with devfs, and other tinkerings.

    Just be aware that quite a bit is moving around in 2.5.x, so nothing is guaranteed to stay stable at all in it.

  • ...it will compile this time. I tend to only get lucky every few kernel versions. Or is that all the bloat I try to compile in *grin*
  • Looks like XFS is still not about to be included in the main development tree, which is too bad since it is a great filesystem. I guess that I am going to have to continue getting my updates from SGI [sgi.com].

    (Getting a kernel via CVS is SOOOO nice) :-)
  • Sure, I'll try 2.5.2.. no big deal. After the 2.4 series, I'm strangely no longer afraid of the development tree. (-;

    ps.) hint to developers: better VIA chipset support!

Slashdot Top Deals

Put your Nose to the Grindstone! -- Amalgamated Plastic Surgeons and Toolmakers, Ltd.

Close