Linux 2.6.22 Kernel Released

An anonymous reader writes "Linux creator Linus Torvalds announced the official release of the 2.6.22 kernel: 'It's out there now (or at least in the process of mirroring out — if you don't see everything, give it a bit of time).' The previous stable kernel, 2.6.21, was released a little over two months ago. New features in the 2.6.22 kernel include a SLUB allocator which replaces the slab allocator, a new wireless stack, a new Firewire stack, and support for the Blackfin architecture. Source-level changes can be tracked via the gitweb interface to Linus' kernel tree."

Comments

Re:What's SLUB?

[nowhere.elysium]

Dude, Google is your friend: http://lwn.net/Articles/229984/

Re:What's SLUB?

[b1ufox]

http://lwn.net/Articles/229984/

There for you, help yourself.

BTW in short plain english, it adds some voodoo stuff to struct page, removes a lot of metadata cruft from the slab allocator, adds lesser and simple locking after removing most of locks which are not required because of the changes in the cache layer.

So if you are running your kernel on a huge farm of processors of the order of thousand(s), you ll find a remarkable memory saving, which is a big overhead in slab allocation.

HTH

Re:GPL v3

[derrida]

I think this is just not true (yet). I haven't read anything in the changelogs.

But is disk IO fixed on amd64?

[Anonymous Coward]

For anyone in the dark, disk IO has been broken sometime after 2.6.17 on amd64.
I thought I was going crazy, being on 2.6.18 and discovering that any disk activity slows down the whole system, let alone accesses to any other disk.

Then I found a 19-page thread on the gentoo forums that says I'm not alone and it's not unique to a particular chipset:
http://forums.gentoo.org/viewtopic-t-482731-start- 450.html
(with evidence that the deadline scheduler may alleviate _some_ of the problem but not the root cause)

And more importantly the kernel bug report here:
http://bugzilla.kernel.org/show_bug.cgi?id=7372

So I'm happy people aren't ignoring the problem. ...Or should I be worried that something so utterly fundamental has been lost in the shuffle across so many kernels in the past year? Amid all the eagerness to add new features since then (virtualization for example, and now complete rewrites of firewire?!?!).

Why can't we have a 2.7 kernel for this stuff?

Re:But is disk IO fixed on amd64?

[cerberusss]

Why can't we have a 2.7 kernel for this stuff?

So, why the trolling at the end of an otherwise good post? I'll quote Wikipedia for the people who have been living under a rock since 2.4:

The development model for Linux 2.6 was a significant change from the development model for Linux 2.5. Previously there was a stable branch (2.4) where only relatively minor and safe changes were merged, and an unstable branch (2.5), where bigger changes and cleanups were allowed. This meant that users would always have a well-tested 2.4 version with the latest security and bug fixes to use, though they would have to wait for the features which went into the 2.5 branch. The 2.5 branch was then eventually declared stable and renamed to 2.6. But instead of opening an unstable 2.7 branch, the kernel developers elected to continue putting major changes into the 2.6 "stable" branch. This had the desirable effect of not having to maintain an old stable branch, making new features quickly available, and getting more testing of the latest code.

However, the new 2.6 development model also meant that there was no stable branch for people just wanting security and bug fixes, and not needing the latest features. Fixes were only put into the latest version, so if a user wanted a version with all known bugs fixed they would also get all the latest features, which had not been well tested, and risked breaking things which had previously worked. A partial fix for this was the previously mentioned fourth version number digit (y in 2.6.x.y), which are series of point releases created by the stable team (Greg Kroah-Hartman, Chris Wright, maybe others). The stable team only released updates for the most recent kernel however, so this did not solve the problem of the missing stable kernel series. Linux distribution vendors, such as Red Hat and Debian, maintain the kernels which ship with their releases, so a solution for some people is to just follow a vendor kernel.

As a response to the lack of a stable kernel tree where people could coordinate the collection of bugfixes, in December of 2005 Adrian Bunk announced that he would keep releasing 2.6.16.y kernels when the stable team moved on to 2.6.17 [2]. He also plans to include driver updates, making the maintenance of the 2.6.16 series very similar to the old rules for maintenance of a stable series such as 2.4 [3].

Re:But is disk IO fixed on amd64?

[gmack]

"Because Linus said so" is in fact not a particularly valid answer. Yes, Linus has the right to choose the development structure the kernel is now using, but that doesn't mean it is the best way to do it for everybody. dropping the distinction between "stable" and "development" versions was a sloppy, lazy move that simply pushed the responsibility for maintaining stable released off onto the distributors. That has essentially duplicated the work a hundred-fold, because each distribution must do the work themselves. We're told that this is a "better" arrangement, but it is clearly only better for Linus and the kernel developers, because they get to do less work and be lazy when it comes to making changes: "Want to rip out the allocator and replace it with a largely untested one? Sure, why not! Making sure everything works is the distributors problem, not ours!"

Except that the old system didn't work at all. There were just too many changes to stabilize in any reasonable amount of time and while the debugging was happening the 2.4.x kernel was becoming so badly out of date that people (and distros) tried to back port changes from the 2.5.x tree.

The result was TWO unstable kernel trees and the vendor trees had a tendency to be even worse. The old system would have left those people using SATA in a worse situation then they are in now. Keep in mind that SATA came out after 2.6.x so the drivers would right now be somewhere in the 2.7.x series kernel still waiting to be debugged and the stable maintainers would be forced to try and backport the SATA drivers once again resulting in two unstable kernels

YOU are the troll

[Aldric]

Linus has repeatedly stated that his code will not be converted to GPLv3. You are either grossly misinformed, or on someone's payroll. If so, they are not getting their money's worth.

Slashdotted, use the cache:

[evanjfraser]

http://kernelnewbies.org.nyud.net:8090/Linux_2_6_2 2#head-650cd139886ede5053ce6b7e1dd080b5378cc521

Re:question on the wireless

[Technician]

Anyways, I was thinking of adding one of these USB wireless accessories.. could anybody here recommend one that has a good track record of working in linux ?

I would recommend using one of the PCMCIA cards instead. Find one that uses the Anthros chipset. I picked up a D-LINK one that was recognised by Dapper Drake. I didn't need to install NDIS Wrapper of Network Manager. I don't remember the model number of the card, but setting it up was as easy as setting it up in Windows except I didn't need to use the setup CD that came with it. Dapper recognised it as an Unknown Wireless. Properties showed it has an Anthros chipset made by D-Link. From there I gave it a static IP on my LAN and plugged in the WEP key after picking my SSID from a list. I added some DNS listings and put in the gateway address of my router and I was online. There have been some difficulty with configuring many of the USB cards. Check the forums and purchase carefully.

Re:Headline does not match the story

[Anonymous Coward]

Dude, you haven't read the links have you?

http://forums.gentoo.org/viewtopic-t-482731-start- 450.html
"... And of course all along I've been experiencing the slowdowns with the SATA (now back to IDE) disk access mentioned at the beginning of this thread."

http://bugzilla.kernel.org/show_bug.cgi?id=7372
"... The only thing related to libata I can think of is NCQ interacting badly with io scheduler..."
"...Yes, and this means that the problem is getting worse with TCQ/NCQ enabled, but
it is not the root cause."

This issue really is about disk IO performance in general, not specifically CD burning! Please don't make light of what is a very serious problem. It was at a point today where I had a hard time even starting "top" today during some DV video playback. Unacceptable.

Re:What is this?

[smittyoneeach]

Indeed, you are a double pleonasm, and should take pride in your superfluous redundancy.

Re:Goto considered harmful?

[Cyberax]

See http://kerneltrap.org/node/553/2131 for explanation. In short, Linus has good reasons to use goto.

Re:New wireless stack? Firewire stack? WTF?

[smittyoneeach]

Your arguably insightful post was kinda flattend in advance by GKH at OLS:
http://www.linux.com/feature/115767

Re:Headline does not match the story

[greg1104]

It would be helpful were you to actually read all of the attached links completely instead of seeing some bogus reports in the Gentoo area and dismissing the whole thing based on that subset.

I'd suggest http://bugzilla.kernel.org/show_bug.cgi?id=7372#c1 08 and http://bugzilla.kernel.org/show_bug.cgi?id=7372#c1 12 as the best summary of the kind of problem people are running into. There are no optical devices involved.

Re:question on the wireless

[vtcodger]

*** Anyways, I was thinking of adding one of these USB wireless accessories.. could anybody here recommend one that has a good track record of working in linux ?***

I'd be careful about anything with a Broadcom chip. There is a Broadcom driver for Linux, but it doesn't always work. The alternative is ndiswrapper which can somehow make a Windows driver work under Linux. My experience was that setting up ndiswrapper was not much fun. Not knocking ndiswrapper -- I'm utterly astounded that it works at all

Re:Anybody

[b1ufox]

Current firewire stack is way too small in size as compared to old firewire stack.

Second now there are less threads in the firewire subsystem, which is indeed good because kernel threads are really really a very stupid idea.

Last but not the least i have used TI firewire chipset with Basler IEE1394 cameras under Linux and trust me they knock teeth out of Windows Firewire stack.It was good and performed good even with two cameras working in real time image inspections.

I suspect the current stack is going to work atleast similar if not better, though i ll bet on it being better.This is a good sign also, as there is no point in patching things but point is in writing the whole messy thing again.And here we are.... hey wait TTY layer ...any takers? please :-)

Re:New wireless stack? Firewire stack? WTF?

[s2jcpete]

Did you read the article? It is not enabled by default, at least till all the drivers get ported to it.

Torrent File

[Anonymous Coward]

Torrent File Here

Re:New wireless stack? Firewire stack? WTF?

[baadger]

Both the 'old' firewire and the 'old' wireless frameworks and their corresponding drivers are still in the tree. If you don't want to use these new and relatively untested stacks then simply don't use them in your 2.6.22 config.

Re:Anybody

[iabervon]

From a user perspective, it doesn't matter, but a number of drivers for releatively new hardware have been written to use it, which means that there will probably be a bunch more wireless cards supported by the mainstream kernel in the next few versions, and one fewer step to get drivers in 2.6.22. For example, Intel has a new driver for their a/b/g card that doesn't require a userspace regulatory daemon or anything (the firmware takes care of all of that), and this driver uses the new stack; they have plans to get this driver into the mainline kernel, at which point live CDs will start having wifi on new laptops with intel chipsets.

In 2.6.22, the new wireless stack isn't going to make any difference, because they haven't included any drivers that use it yet.

Re:Anybody

[Anonymous Coward]

Some info here:

http://liquidat.wordpress.com/2007/02/06/kernel-26 20-still-no-new-wlan-subsystem/

http://liquidat.wordpress.com/2007/03/02/new-linux -wlan-subsystem-integrated-into-mm-kernel-tree/

http://www.devicescape.com/news/releases/release_0 5-01-06_opensource.php

BTW, Fedora and Ubuntu already include the new stack with their own patches.

Re:question on the wireless

[MSG]

I presume you mean "Atheros". I recommend not using those cards. Atheros cards do not have Free Software drivers; they're binary-only. They don't handle suspend well, which is kind of a big issue when you're dealing with a laptop. Ralink or Intel cards are a much better bet.