Linux Kernel 2.6.3 Has Been Released [updated]
justinarthur writes "At 04:36 UTC, Linux kernel version 2.6.3 has been made available. As is typical, downloaders are advised to utilize a mirror upon file availability. There are many changes from version 2.6.2, including recent ALSA patches, XFS fixes, and updates in many other areas." Update: 02/18 14:15 GMT by T : Peter Willis points out that kernel 2.4.25 (changelog) was also released, and writes "Incidentally, a security advisory dated today states there is an exploit in kernels up to 2.4.24 and 2.6.2, but the two releases today don't seem to reflect any changes, so get ready to patch up as soon as a patch pops up. More details on the vulnerability here."
Wait until 2.6.4 when that code has been removed.
I have been pwned because my
I must admit to being a little disappointed right now with my Gentoo installation. I saw the article here, ran an emerge sync, and 2.6.3 is still marked as unstable. I guess I'll have to wait 15 minutes before I can install it... ;)
On a slightly related sidenote, whichever developer it was who "broke" support for the 105th key (the "Europe" key) in 2.6.1 should be drawn and quartered. It took me forever to figure out why my tilde key wasn't working. I created a text file called tilde with the character in it so that everytime I needed a tilde, I could copy and paste it... Aaarrggh
KernelTrap reported "large merges" to 2.6.3-rc2, including:
network driver updates, compiler warning fixes, PPC updates, a major ALSA update and SCSI updates, NFSv4 update, XFS fixes, ARM and sparc updates
At a tidy 9472 lines, I think the word 'summary' needs a new definition...
Any idea when we'll start seeing 2.6 as the kernel included in the big distributions?
Those that wants detailed changelogs, or just wants to follow the very very latest changes/additions to the kernel source tree can do so here
2.4 kernel tracking can be done here
I still haven't upgraded to 2.6.2!
I grabbed the patch, applied it, reconfigured, recompiled, and set up grub. I've been waiting and waiting but still have not suffered a single crash, so I have been unable to justify rebooting.
I want my Cowboyneal
Is there already any distro with the kernel 2.6 series? I'm still waiting for the response of the market before going for kernel 2.6 yet. My 2.4.24 is really stable and running fine, but I'm anxious to see the threads improvements in 2.6...
Ronaldo Faria Lima
E-mail:ronaldo@ronaldolima.eti.br
Home page: http://www.ronaldolima.eti.br
Just curious, how you get the 10%? System boot time, Executing application,...? btw, I mod your first post up...
And I don't mean having feline carnal knowledge.
And thanks for personally helping me customize one of the joystick drivers once-upon-a-time many moons ago.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
[ACPI] nforce2 timer lockup from Maciej W. Rozycki
:)
:D
Oooh, does that mean I can finally enable both APIC and ACPI support in the kernel without experiencing lockups on my Nforce2-based system? I've been waiting for quite a while for this patch to go in.
But weren't there supposed to be two (complementary) patches for this problem out there?
len.brown@intel.com
Thanks Intel guy, for allowing this AMD fix to go in.
"Oooh, does that mean we get to kick some puffy white mad zionist butt?"
Previous kernels have never worked entirely well with my Mobile Radeon M6-P graphics card. Switching from radeon-powered X to radeonfb-powered console, or changing the resolution within radeonfb, would occasionally cause the screen to get all fuzzy, making me switch back and forth until it looked normal again.
But with the 2.6.3 kernel, there's a kickass new radeonfb driver that doesn't have any of these problems, and has improved collaboration with the BIOS to decide certain settings. No longer will peers think Linux must suck because my screen occasionally gets fuzzy.
However, I'm still only getting 435fps in glxgears with a 16MB graphics card at 1024x768 with DRI definitely on. Is this normal for a sucky notebook display card, or is there a problem with Linux's radeon gl support or my settings?
I'm just waiting for the I20 drivers to finally compile cleanly in 2.6. I haven't been able to compile 2.6 on a server here because it requires I20 support that is apparently broken. Bummer...
According to the changelogs, Debian and Slackware already have the patches for the bounds checking error in place. I didn't check the other distributions. (Or rather, I don't know where to check most of them quickly.)
The bug's still there. :(
/dev/hdX" (hdX being your harddrive) from the root prompt a couple of times.
The lockup can be easily triggered by running "hdparm -t
I know, I know, it's easy (as well as unfair) for me to bitch and moan, since I'm not a kernel developer. But knowing that there are patches out there that could solve this problem, but still haven't made it into the kernel, it's frustrating.
For what it's worth: I haven't noticed any speed advantages between an APIC-enabled and non-APIC-enabled kernel, so I guess it's not too much of a loss.
Does anybody here have any better experiences with this?
"Oooh, does that mean we get to kick some puffy white mad zionist butt?"
At least acording to Linus .
The 2.6 series doesn't have support for HFS+ disks yet. (2.4 did.) Anybody feel like porting the latest HFS+ driver to 2.6? :-)
Sometimes the sqeeky justice wheels sound just like hamster wheels.
..when I say "Squeeky wheel gets the kick! Go for the eyes Boo!"
Belief is the currency of delusion.
The cause is a brand new ACPI implementation which has a cutoff date of January 1st 2001. If your computer's BIOS is older than that, any ACPI support that might be present will be completely ignored by the kernel. ACPI hacker Len Brown explains that while the cutoff date is indeed arbitrary, it was already being used by certain distributions who noticed a pattern in when BIOSes with broken ACPI support where manufactured, so the ACPI hackers stuck by that concensus.
If you know for fact that ACPI worked fine on your computer until 2.4.21, you can enable it again: the cure is to put acpi=force in your bootloader configuration options.
Len also noted that there might eventually be a whitelist of older BIOS versions whose ACPI support is spotless. If you feel that your motherboard is one of those that should be whitelisted, file a bug at Kernel.org. Len makes absolutely no promise whatsoever that such a whitelist will ever be implemented, but still leaves the door open for people to manifest their interest via the above bug report form.
Software is not supposed to be about how to work around a useability issue. - Ken Barber
I just totally rebuilt my systems with gcc-3.3.2 / glibc-2.3.2 / kernel-headers-2.6.1, I had to drop a few packages, but overall everything works splendidly. I'm in that teensy little group of people who actually have an entire system built against the NPTL thread libraries.
Honestly, I don't notice much of a difference, just some 'different' behavior when I'm loading the system. It's not like things compile ten times faster or mozilla opens in much less time. I noticed that my system 'loads' differently now, full-speed network transfers tend to take all the unused CPU power, but only when no other processes want it. Before, under 2.4, full-speed net transfers would only tax my CPU to about 10%, but I suppose having the slightly greater throughput at the cost of 'junk' cycles makes sense, it's probably a high-res timer kicking in to make sure the NIC is 'properly fed'.
This weekend I'll be rebuilding my PPC and x86 machines AGAIN against gcc-3.3.3 / glibc-2.3.2 NPTL / linux-headers-2.6.3, I think I'll give the advanced IO-APIC a try too. I'm hoping 2.6.3 will fix some of those broken packages on PPC. Wish me luck!
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails