Linux Kernel 2.6.24 Released

LinuxFan writes "Linus Torvalds has released the 2.6.24 Linux Kernel, noting that he and most of the other key Linux developers will be flying to a conference in Australia for the next week. As the whole team will be down under while the kernel is being tested by the masses, Linus added, "Let's hope it's a good one". What's new in the latest release includes an optimized CFQ scheduler, numerous new wireless drivers, tickless kernel support for the x86-64 and PPC architectures, and much more. Time to download and start compiling."

Comments

Wow. Lots of stuff.

[MostAwesomeDude]

On one hand, things like the VM dirty writeback adjustments and default cpufreq frequency governors, as well as dynticks for more arches, are big performance improvements. On the other hand, they broke wireless packet injection patches for a lot of drivers... At any rate, I'll have to try this just to see if it really performs better. Things like laptop_mode which rely on optimized scheduling and writeback code should see improvements.

Merge Window?

[AndGodSed]

"Since I already had two kernel developers asking about the merge window and whether people (including me) traveling will impact it, the plan right now is to keep the impact pretty minimal. So yes, it will probably extend the window from the regular two weeks, but *hopefully* not by more than a few days."

Now THERE's confidence for you. Great news.

Re:Merge Window?

[Anonymous Coward]

I'm just wondering, should a core group be traveling together? What will the impact be if that plane impacts the ground?

Re:Merge Window?

[iMaple]

There is a chance that some stupid airline CEO decided that their planes use The Evil Darklord's software for navigation. Of course we all know that noone would NEVER code a special condition in the software which says

if(passenger_list.contains(entire_linux_kernel_team){
      flyinto(mount_everest);
      output_evil_voice("muhahahhaa");
}

On the other hand, there is nothing to worry about. This feature probably was shelved and is definitely going to be in the *next* version of the OS.

Re:Merge Window?

[WarJolt]

*New builtin* The entire linux team was traveling to a conferance after releasing their final kernel. The pilot were recorded screaming "AHHHH BLUE SCREEN OF DEATH" Followed by an explosion of the right engine. The plane fell out of the sky moments later.

Re:Merge Window?

[Anonymous Coward]

Do they have wireless internet access on Mount Everest ? Its a well known prophecy that Linus can not die, till the dark lord reigns, so all he needs is internet. He'll be on a programming high I guess.

Re:Merge Window?

[Aladrin]

Did you seriously just managed to misspell both words in 'News Bulletin'?

Re:Merge Window?

[Anonymous Coward]

DId you seriously just manage to screw up correcting someone else?

Re:Merge Window?

[mabinogi]

No, it's a new built-in feature in 2.6.24

Re:Merge Window?

[arkhan_jg]

DId you deliberately screw up that correction of a correction? You did, didn't you.

Re:Merge Window?

[clem]

This is just the kind of discussion that would be greatly enhanced if only there were a means of flinging poo over the Internet.

Re:Merge Window?

[WarJolt]

Too much late night slashdotting.

Re:Merge Window?

[ptudor]

Awesome.

Re:Merge Window?

[Dolda2000]

Did you deliberately screw up that correction of a correction of a correction? You did, didn't you?

Still no orinoco monitor mode

[Anonymous Coward]

The orinoco wireless drivers have supported monitor mode since 2004. Still not in the kernel today. Do any of the BSDs support monitor mode yet on this incredibly well documented chipset? I'll migrate if the answer's yes.

Re:Still no orinoco monitor mode

[Creepy Crawler]

---The orinoco wireless drivers have supported monitor mode since 2004. Still not in the kernel today. Do any of the BSDs support monitor mode yet on this incredibly well documented chipset? I'll migrate if the answer's yes.

Good point. Would anybody more enlightened than I explain why the good orinoco drivers arent accepted in the kernel?

Evidently asking questions like this is flamebait... but why is this so WRT the kernel?

Re:Still no orinoco monitor mode

[MostAwesomeDude]

What I would like to know, personally, is why the aircrack-ng patches for injection (http://patches.aircrack-ng.org/) are still out-of-tree.

Re:Still no orinoco monitor mode

[Creepy Crawler]

I can see why with aircrack...

Look at their release dates and patch revisions... none current. Kernel guys like seeing constant and timely patches. Community members who slack off are considered bad and all..

But I guess the wireless guys dont like these addons... Good for them, bad for us.

Re:Still no orinoco monitor mode

[Xabraxas]

What I would like to know, personally, is why the aircrack-ng patches for injection (http://patches.aircrack-ng.org/) are still out-of-tree.

As far as I know the new mac80211 wireless framework supports injection for any driver that uses it. You need to be running a beta version of aircrack-ng to take advantage of it though.

tickless kernel support?

[Mr2cents]

Can anyone explain to me what "tickless kernel support" is?

Re:tickless kernel support?

[MostAwesomeDude]

Can anyone explain to me what "tickless kernel support" is? Sure. Basically, instead of having a regular tick in the kernel every handful of cycles to process interrupts and timers, processes are given long, dynamic timers with arbitrary lengths, which means that if an app wants to sleep for a relatively long period, it gets to sleep and not wake up the CPU, so the CPU sleeps longer and a lot of power is saved.

Re:tickless kernel support?

[JohnFluxx]

Does this also mean that an app can also sleep for a very short period? Normally a sleep function is limited by the granularity of the kernel ticks. Will this make sleeping for, say, 1ms more accurate and reliable?

Re:tickless kernel support?

[Andy Dodd]

There is another patch that adds high resolution timers to Linux. (Actually, another component of a gigantic patchset that has been rapidly getting mainlined over the past few kernel releases.)

I think CONFIG_HRTIMERS is already an option (may not default to on though). If it isn't, go find the RT_PREEMPT patchset. That includes (or if HRTIMERS is in the kernel, included) HRTIMERS, it's also where the NO_HZ option came from.

Re:tickless kernel support?

[Daimanta]

Basically, it prevents the computer from being ticked off thus preventing a hostile robot takeover.

Yeah tick less is fine stuff

[emj]

Reducing wakups on laptops is very interesting suff, I've seen some post on how muche better the NO_HZ is making things, e.g. Ross went from 164w/s to 5w/s just waking up 5 times per second makes the CPU pretty cool...

more power save links

[emj]

I was going to post this on Thinkpad wiki on power consumpton, but sadly the page is not working atm..

Yay!

[Tribbin]

It's always a nice read in the morning, that you don't need module-assistant anymore.

(rt61 Wireless)

Bang up job

[Smordnys s'regrepsA]

Don't worry, I'm sure their rocket-launcher's computer's tracking interface will freeze up just moments before they press the fire button, so they'll have to fire it by visuals. Then, it will tragically fire 5 minutes later, while they're bashing the thing against the ground trying to get it to Just Work.

I am really grateful for this release

[eclectro]

The weekend is almost here, and I am looking for something to do. I want to argue about the scheduler.

Re:I am really grateful for this release

[mightyQuin]

You just made my morning!
Let us also digress into a micro-kernel vs monolith-kernel discussion.

Re:I am really grateful for this release

[phobos13013]

would you believe i JUST upgraded to 2.6.23-r3 on Tuesday? I'm a kernel holdout, but hey, at least its better than the people who have been holding out to upgrade from 2.4.xx!!! Yea, the only reason I had to upgrade too was frickin gentoo dependency, I think because of KDE-base, whatever....

Re:I am really grateful for this release

[ajs318]

Let us also digress into a micro-kernel vs monolith-kernel discussion.

Oh, that's an easy one. With a microkernel, you put up fences where they look pretty. With a monolithic kernel and loadable modules, you put up fences where as little stuff as possible has to traverse them. Ting! Next, please.

Re:I am really grateful for this release

[mac1235]

Oh no, this abuse. Arguments are down the hall.

Re:I am really grateful for this release

[nagora]

Arguments are down the hall.

No they aren't!

Re:I am really grateful for this release

[cbart387]

Don't forget to compare the amount of _stable_ releases of Linux kernels (anyone have a number?) versus the GNU Hurd (zero). Didn't HURD development start almost a decade before Linus started on his work?

Re:I am really grateful for this release

[0xABADC0DA]

With a typesafe kernel like monotone or jxos everybody has a personal force field bubble around them that nothing crosses, and they just point at stuff outside their bubbles. Also, there are no laws because the force fields keep everybody perfectly safe all the time.

Re:I am really grateful for this release

[JackieBrown]

You should have just skipped to the stable one then instead of using an outdated rc.

Re:I am really grateful for this release

[dbIII]

It was really about "we are a small team and we will do it all but you can join us if you can prove you are truly uber" to the linux "send patches and I'll use them if they look good". I just never got to feel like one of the hurd.

The timing really meant that a lot of people thought they would not be welcome adding to the hurd by the time they got fast net access while linux was still new and welcoming.

Anti-Fragmentation?

[kripkenstein]

The updates most interesting to me are the anti-fragmentation patches,

Tests show that about 60-70% of physical memory can be allocated on a desktop after a few days uptime. In benchmarks and stress tests, it has been found that 80% of memory is available as contiguous blocks at the end of the test. To compare, a standard kernel was getting ~1% of memory as large pages on a desktop and about 8-12% of memory as large pages at the end of stress tests.

Perhaps someone can clarify exactly what this means? Reading the beginning, it talked about 4K pages, device drivers, and such, so I assumed it would just be relevant to the internal workings of the kernel. However, the quote I pasted above seems to indicate it might impact desktop performance as well.

I commonly see on my desktop, after several days uptime, that quite a lot of memory is being used (and I know how to ignore cache/buffers, as well as swapcache - that isn't the issue). Logging out and logging back in returns memory to reasonable levels (and the system becomes more responsive, but then I guess if I bought more memory I could accomplish that as well). Now, I've generally read that the problem was indeed memory fragmentation, e.g. here, but this would be internal fragmentation inside an app, and thus not relevant to the kernel, I believe? If someone can explain this issue I'd be grateful.

Re:Anti-Fragmentation?

[pmontra]

I googled a little and found this article http://lwn.net/Articles/211505/. I'm not sure that this is all of the story, but it should be a good starting point for further investigations.

Re:Anti-Fragmentation?

[Anonymous Coward]

He's talking about how the memory blocks allocated to user programs are actually laid out in physical memory. Think of it like this: if we have programs A, B, C, and D using memory (and F for free), before the physical memory may have been allocated something like this:
AAFBBFABCFCDBACDDBAF (not contiguous)

And now more like this:
AABBBAFFFCCCCDDFFFFF (free memory is in large contiguous chunks)

This is not something that userspace programs will notice directly, but it does affect performance of the machine. Keeping free space and other areas contiguous allows for better caching performance and faster access.

Re:Anti-Fragmentation?

[cbart387]

It sounds like it's talking about memory management for external fragmentation. Here is an article that looks like it is talking about those patches. Here is a site that seems to explain memory management pretty well. I could try explaining stuff myself but I'd probably miss some of the nuances (I'm no OS expert by any stretch).

Re:Anti-Fragmentation?

[justthinkit]

I am curious if any versions of Windows provide this feature. If not then chock one up for Linux...

Re:Anti-Fragmentation?

[Hatta]

Why is memory fragmentation a problem? It's not like your RAM has to move a physical head to read non-contiguous blocks.

Re:Anti-Fragmentation?

[Azarael]

After your system has been up for a while, the list of 'free memory' updated by malloc() and free() gets fairly fragmented into odd sizes, that are spread out (especially if you aren't allocating in sizes near powers of 2). The more fragmented this list gets, the longer it takes for malloc to locate a block of memory that fits the size that you want. If I understand correctly, this change should make it possible to keep the free list more organized.

Re:Anti-Fragmentation?

[X0563511]

It does make sense. When your ram passes a row to the CPU caches, it's nice when most of that row is related somehow. The large blocks of free space help ensure that A/B/C/D/E don't get all mixed up next to each other.

Re:Anti-Fragmentation?

[X0563511]

Correct, but unlike your hard drive, RAM is fetched into cache for processing in "rows", and there is only room for so many rows. The more related stuff is together in RAM, the less "swapping" rows in/out of cache occurs. With multicore systems, this is even more important, as processors must synchronize to be sure they don't manipulate data cached by the other core... further dragging things down as more RAM access occurs.

Just like the hard drive is orders-of-magnitude slower than RAM, RAM is orders-of-magnitude slower than cache, is only read/writable 20% of the time or so (refreshing, row/column selecting, etc)

Re:Anti-Fragmentation?

[spitzak]

malloc allocates pieces of the processes virtual address space to the program. All this fragmentation disappears when the program exits, so this is not exactly a problem with "the system being up for awhile". However similar problems exist in the kernel memory allocation and those problems do persist until the system is rebooted.

As far as malloc goes, I don't believe fragmentation really slows it down, it has algorithims for immediately identifying a block of sufficient size, and does not do a search. It may slow down freeing slightly. The real problem is that all the useful items end up spread over a much larger amount of virtual memory and thus uses a lot more of it. This means more swapping (further made painful as lots of those swapped pages are partially filled with pieces of free blocks), and it also means malloc may fail to allocate something because no free block is big enough and your program will crash. And it means inefficiency in loading stuff into cache memory.

The system has some advantage that the use of VM means that (in most cases) it does not need to fit an allocation request in one hole because it can split it up into seperate pages (exceptions are where hardware actually requires contiguous real memory addresses). Also it only works with pages so if swapping happens it does not waste time reading/writing the data in the holes. But as many pointed out, if the memory is not contiguous then it does not load into caches efficiently, as the modern caches are far larger than the pages.

Re:Anti-Fragmentation?

[kelnos]

Modern CPU cache lines are typically on the order of tens or hundreds of bytes. Yes, bytes. Not kilobytes. Memory fragmentation doesn't really affect CPU caching. Fragmentation does, however, affect allocation/deallocation performance as well as application memory access speed.

Re: Anti-Fragmentation?

[Dolda2000]

I'm not sure exactly how this works, so I can't go into all too nitty-gritty details, but basically, it's like this.

x86 CPUs (and probably amd64 as well) allow the kernel to choose between two page sizes: The usual 4 kB ones and a much larger size (I think it's 1 MB or so). The performance issue is that if the kernel can keep the physical RAM pages that back a large contiguous virtual mapping contiguous in physical RAM, it can use one of the jumbo pages instead of potentially hundreds of 4 kB pages. Doing so saves both page table space by itself, but more importantly, it allows the CPU to cache the page table in much fewer TLB rows. If a 1 MB mapping can be cached in one TLB row, the CPU won't need to swap TLB entries back and forth from the physical page table. Even if the page table may be cached in the normal CPU memory cache, it would still result in far better bus performance.

wireless drivers

[oliverthered]

Could someone provide a quick summary of the wireless drivers that are now in the kernel as I don't know the chipset names for them and one of the sites appears to be /.ed.

Re:wireless drivers

[Jack Malmostoso]

There you go:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/net/wireless;h=45adf0a95539e8a0ca5fddbb720319a9b7b39978;hb=HEAD
If you want a suggestion on what to buy, support for Intel chipsets is very good. I have a 4965 device supported by iwlwifi and it works like a charm.

Re:wireless drivers

[schon]

If you want a suggestion on what to buy, support for Intel chipsets is very good. Unfortunately, unless you're an electronics engineer, purchasing a chipset doesn't do you very much good unless it's already on a card, and card manufacturers don't advertise which chipset is on a specific card (in fact, chipsets in many of the cheap cards get changed with other ones from batch to batch - I guess the cardboard boxes are more expensive to change than the electronics on the card.)

I'd love to get a wireless card with an intel chipset, but try finding a card that says they use them.

Re:wireless drivers

[Enleth]

In the case of a laptop, that's easy. Intel makes the whole MiniPCI card and markets it with their brand. With a desktop, you can either try to find a working PCI card, or just... Well, buy a MiniPCI->PCI converter for $10 or so and you're done. That's what I did.

Re:wireless drivers

[leoxx]

Does the 4965 driver support LEAP yet?

Re:Mirror list

[TeknoHog]

Is there an active and/or "official" Bittorrent site for Linux kernels? The local mirrors take some time to update, so global torrents would make more sense. Besides, people who download kernel sources are usually the kind that appreciate the benefits of BT and know how to use it.

Catching up to Windows on power

[dpilot]

From everything I've heard, Linux is still only catching up to Windows in terms of power consumption. It's fun because we hear all of the details, and until someone builds some nifty package, we script all of the dial-tweaks ourselves. Part of the fun is knowing the dials and what they do, but I guess that's not fun for everyone, some want it to just work, and we're getting there. As long as I can still see the dials, understand them, and tweak them, good automated default power management is good, too.

But from a methodology viewpoint, does anyone understand the road Windows has trod, and how they have gotten to where they are? For instance, things like the tickless kernel are pretty fundamental. Is the Windows kernel tickless, or how do they get their power down if it isn't?

Re:Catching up to Windows on power

[JasterBobaMereel]

What you do is you get the hardware manufacturers to write their device drivers to your specs so you can rely on devices going to sleep and waking up properly and reliably then you can write easily make the system consume very little power

The you write the system so that it uses more memory than you have and so swaps to disk constantly so that it uses huge amounts of power when working and only saves any power when the whole system goes to sleep ....

Re:Catching up to Windows on power

[Andy Dodd]

Windows power management used to SUCK in early versions of XP. XP's support for SpeedStep on Pentium 4-M CPUs was abysmal, for example. The Windows 2000 SpeedStep app from Intel (which didn't work in XP) was lightyears ahead of what XP had built in. Back in 2001-2002, Linux could easily blow away a Windows machine in terms of power consumption. Since then XP has improved due to lots and lots of "behind the scenes" tweaks, and to some degree, hardware manufacturer cooperation.

For example, one of the few things the Linux NVidia drivers still don't support well is power management. (ATI isn't any better in this regard though.)

Re:Catching up to Windows on power

[Anonymous Coward]

Then you probably heard wrong. You might be confusing it with ACPI support - a standard which Windows does not implement correctly, which Microsoft give away defective tools for implementing (resulting in defective support for ACPI on many machines, particularly laptops), and which manufacturers support by testing against Windows only. It works in Windows only because hardware manufacturers make it work in Windows, but tends not to work so well in Linux.

In all other respects, Linux is way ahead on power consumption. Things like a tickless kernel, or tools like PowerTOP simply don't exist on Windows. If you have a laptop that's well supported under Linux, it'll tend to last a lot longer than it does under Windows.

Comparing to Mac OS X is a different matter entirely.

Re:Catching up to Windows on power

[darkwhite]

The original poster heard right, and you're spreading misinformation. Windows XP is way better at conserving battery power than Linux. Tools like powertop and tickless have been enabling great improvements in power consumption but it's still nowhere near that of XP.

Re:Catching up to Windows on power

[ThePhilips]

It is sad reality the people keep mixing up technology and products.

Linux (as kernel and piece of technology) is far ahead of most OSs in power management and especially in power saving.

But. Take fresh Windows XP installation - it would give you decent up-time from single battery charge. Take Mac OS X - it would give you excellent up-time from single battery charge. Now take Linux's distro with X.Org/GNOME/KDE/etc - and it would eat any battery in under two hours.

It is possible to optimize Linux to be extremely power efficient, yet lion share of applications written for PCs simply fail on portables.

From recent example. I'm reading lots of PDF ebooks - under Mac OS. Trick is to scroll document to the end and then go back to place were you stopped: Mac OS would cache the file and hard drive will not wake up for the whole time you read thru the PDF. Linux? - Ubuntu/Kubuntu/SUSE/YellowDog were tried - hard drive is always spinning. Always. Non-stop. I stopped even trying to investigate what keeps it spinning - just went back to Mac OS. Because battery lasts under Linux for about 2 hours - while Mac OS on the aging iBook easily does 6 hours. But honestly, even if battery charge set aside, the noise produced by constantly spinning hard drive me slowly crazy.

Conclusion: excellent power management of kernel != end-user application are designed with power efficiency in mind.

P.S. Most common offenders are X.Org with its ~/.xsession-errors (as if end-users cared about all the cruft in there - developers simply do not look there at all) and syslogd which periodically (by default every 20 minutes) write marker into logs.

Re:Catching up to Windows on power

[sentientbrendan]

>Linux (as kernel and piece of technology) is far ahead of most OSs in power management
>and especially in power saving.

I doubt this is true. Do you know for a fact, for instance, that none of the other two major operating systems don't already have dynamic ticks? How many people on slashdot are familiar with the windows kernel? You don't have to work at microsoft to get these architectural details (windows architecture is detailed in a number of books, and university students often have access to windows source), but it is somewhat esoteric knowledge. Linux is the only operating system where kernel changes are highly public.

I've observed that people tend to assume that when something comes out for whatever platform that they have, it must have just been invented for their platform. In reality, people tend to reinvent the wheel a lot, and not that much real innovation occurs in operating systems. Innovation looks like it occurs, because any given operating system is missing features present in some other operating system and they only slowly converge.

Apple in particular tends to borrow architectural features from other operating systems, and their primary innovation tends to be how their plug everything together and package it up just right. Often they simply port existing software and keep interfaces intact. OSX has API's ported straight from macintosh, unix, and even windows (they have some minimal COM support).

Both the Linux community and Microsoft on the other hand have an enormous case of Not Invented Here, and tend to take the basic idea of some existing feature, and reimplement it in an incompatible way.

Microsoft is a fan of writing big frameworks that tightly integrate with other Microsoft technologies. This is real nice if you only ever want your software to run on windows, but those same frameworks tend to be so large that it complicates porting both software that runs on the framework and the framework itself.

The Linux community on the other hand likes to develop a number of incompatible frameworks that do the same thing simultaneously (e.g. sound frameworks that fight for control of the sound card). People tend to ignore standards both from other operating systems and from within linux, as everyone has their own idea what the ideal Linux should behave like. I'm not the first person to observe that Linux would benefit massively from a single good system architect to coordinate and discipline the effort at a high level. Someone like Linus, but responsible for the whole stack instead of just the kernel.

Re:Catching up to Windows on power

[MostAwesomeDude]

Go grab laptop-mode-tools (I guarantee it's available for your distro) and a kernel newer than 2.6.10, and then enjoy. Among other things, your hard drive will only spin up once every 10 minutes at most if you're not requesting reads or writes. It's possible to beat Windows in battery usage very easily -- Windows can't do things like power down the USB buses if there's nothing connected or requesting power, or sleep the CPU for 99% of its ticks.

Re:Catching up to Windows on power

[Ant P.]

The xsession-errors file is doubly useless in that it deletes itself when X exits.

The real worst offender would have to be Konqueror though, which calls sync() Every. Time. It. Uses. The. Cache.
For example, opening a html file in it containing just the line "<meta http-equiv="Refresh" content="0">" will keep your hard disk light perpetually lit.

tuxonice?

[Lord Kano]

Does anyone have an idea when tuxonice will be re-merged? I know that most of the heavy lifting is done is userspace, but it would be nice if we didn't have constantly track down patches.

LK

Tickless kernel now supports high res timers

[Anonymous Coward]

In previous non-realtime Linux kernels the calls to nanosleep() or usleep() that were less than one tick (10 milliseconds) were rounded up to 10 milliseconds. This can be very frustrating when writing embedded software that needs responsive timers. Now the resoultion is down into the microsecond range with current CPUs and will scale down even further with faster CPUs.

Text-only Google cache of kernelnewbies.org site

[kazade84]

Here: http://64.233.183.104/search?q=cache:KUKtLm1iDokJ:kernelnewbies.org/Linux_2_6_24+http://kernelnewbies.org/Linux_2_6_24&hl=en&client=firefox-a&gl=uk&strip=1

eCryptfs persistent files

[omnirealm]

In 2.6.24, eCryptfs overhauled its I/O mechanism with the lower filesystem (check out fs/ecryptfs/read_write.c). It used to directly manipulate the lower inode address mappings, which caused problems with certain filesystems like NFS (they like to be the only filesystems directly locking, reading, and writing their own address mappings). Now it opens a persistent lower file for each and every stacked inode and uses that for all I/O with the lower filesystem. This significantly decreases the complexity of the execution path for reading and writing the lower data. Together with this patch, eCryptfs now works pretty well on networked filesystems like NFS and CIFS.

There is another patch to provide HMAC integrity enforcement, and the kernel GIT tree for eCryptfs has a branch indicating that filename encryption is being worked on.

Re:more power save links

[Nukenbar]

A lot of links don't work 'at the moment' when you post them on Slashdot!

Re:Video drivers

[tamyrlin]

X usually opens /dev/mem and used mmap() on it to be able to read and write to the appropriate place. If you use a card with DRI support in Linux you will have some kernel support as well.

(Unless you use vesafb or some similar video driver.)

Re:Next "stable" release?

[Hatta]

It would be nice if you described the problems you've had with recent kernels. I haven't noticed any instability.

Re:does Debian/Ubuntu make upgrading easy too?

[Randle_Revar]

You mean outside of waiting for an official package?
There is a package called kernel-package that makes thing a little easier and produces a .deb that you can install with "dpkg -i"

http://myrddin.org/howto/debian-kernel-recompiling/
http://www.debian.org/releases/stable/i386/ch08s06.html.en

or http://www.google.com/search?hl=en&safe=off&q=kernel+debian+way

working great here...

[FudRucker]

i build as much as possible the only required support for my hardware specifics as modules except for ext3 filesystem support (built in to the kernel itself) thus making an initrd unnecessary, my kernel is nice & light, highly responsive and boots in just about 10 seconds, and the kernel is only 1.1 megs in size & /lib/modules/2.6.24 is 11 megs...

Re:Next "stable" release?

[Randle_Revar]

I haven't seen stability problems in 2.6 for a long time. Lately I have been using the 2.6.24 (pre-release) kernel from Ubuntu Hardy (I'm on Debian Sid), and I haven't had any trouble with the kernel. X.org and Mozilla nightly problems, sure. But no kernel problems.

Re:Video drivers

[Randle_Revar]

And the DRM kernel stuff will be getting upgrades soon

http://www.linux-foundation.org/en/Linux_Weather_Forecast/hardware#The_TTM_memory_manager
http://www.x.org/wiki/ttm
http://wiki.x.org/wiki/DRI2

Re:Next "stable" release?

[WK2]

That partly depends on what you want to do. I'm just a regular guy, and the kernels in Debian Stable and Debian Testing work for me. I don't know what to say if you're trying to write a device driver or something. But one of the things that distros are for is a stable Linux kernel.

Re:Next "stable" release?

[Spazmania]

Random kernel lockups with a 9-way IDE software RAID on a 1.2ghz Athlon under 2.6.17 and 2.6.18 is the first thing that jumps to mind. Massive interrupt error counts when using more than one channel on Promise IDE controllers on the same.

I haven't tried it on 2.6.>20 and I don't plan to until someone does like was done with 2.6.16 and declares a stable version that will continue to receive bug fixes but not destabilizing new features.

I understand that there are some folks who find it immensely entertaining to try out the latest, greatest kernel but I'm not one of them. I have better things to do with my time.

Re:Mirror list

[arunkv]

There's a torrent up on Mininova - http://www.mininova.org/tor/1128409

& now back to our regularly scheduled programm

[RLiegh]

OMG teh Steve Ballmer will throw a chair at teh plane!

Re:Next "stable" release?

[Spazmania]

Which is just a swell theory until you realize that most distros (I'm lookin' at you, Red Hat) do a lousy job of stabilizing the kernel for release. Even with one that does it well (debian) its still unhelpful if you happen to need to run several distros and several versions of each (as is not uncommon in larger deployments) and would like a single kernel that's reliable on all of them.

Re:more power save links

[abbe]

That is due to their being posted on Slashdot. Heard of Slashdot effect, hmm...