Weekly Edition
Return to the Kernel page
| |||||||||||||
Kernel release status
The current 2.6 prepatch is 2.6.16-rc3, released on February 12.
As would be expected for this phase of the development cycle, the additions
are mostly fixes, but 2.6.16-rc3 also contains a patch to export the
system's CPU topology in sysfs, parallel port support for SGI O2 systems,
administrator-changeable permissions in configfs, an OCFS2 update, the unshare() system call,
and various architecture updates. See the
long-format changelog for the details.
The mainline git repository, as of this writing, holds about 100 fixes merges after 2.6.16-rc3. The current -mm tree is 2.6.16-rc3-mm1. Recent changes to -mm include some memory management system call tweaks (see below), the EXPORT_SYMBOL_GPL_FUTURE() macro (see below), and various fixes. The current stable 2.6 release is 2.6.15.4, announced on February 10. This one contains a fair number of fixes for crashes and other undesirable behavior. (Log in to post comments)
Kernel release status Posted Feb 16, 2006 8:52 UTC (Thu) by malor (subscriber, #2973) [Link] 2.6.15 in general is truly terrible. I can't keep a bog-standard P4 box running, on an Intel 865 chipset... expected time to kernel panic is maybe 30 minutes under very light load. And I can't easily troubleshoot it, because that box is hosted elsewhere and I have no physical access. My Athlon servers are unstable with APIC mode on; I have to specify noapic to get them to run for more than 12 hours. (VIA chipsets... admittedly not great, but early versions of 2.6 were just fine.) 2.6.14, though it had the APIC problem, at least ran okay on the 865. Except, of course, for the constant reboots from security patches.
They're moving way too fast, shoving new features down our throats so quickly that there's no time to shake them out. They're forcing all of us to be beta-testers. They _need_ to go back to the old system of leaving the code alone and letting it stabilize, instead of just waving their hands in the air and expecting 'the distros' to fix it. The Debian kernel team, at the very least, seems to be mostly just pushing through the vanilla kernel. Without the financial backing of a big outfit like Red Hat, they don't have a QA lab and can't do much testing. They don't have the resources they need to polish the 2.6 turds to a usable sheen.
Since the kernel devs can no longer be bothered with shipping a stable kernel, Debian would appear to be in real jeopardy. I know I've certainly wished for Red Hat on my servers a number of times over the past several months. And I've already started converting firewalls over to OpenBSD; Linux is faster and has more features, but the constant stream of security-related kernel patches makes it very difficult to run on boxes that need to be both secure and up all the time.
Remember actually being _proud_ of your kernel uptime?
Kernel release status Posted Feb 16, 2006 10:05 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] first off there have been bad releases under every kernel development model.
secondly, there have not been many reports of problems like you describe to the kernel developers (there has been one random reboots thread on the list in the last week or so) so it'a likly that you experiance is not the norm.
That doesn't mean that you aren't experiancing real problems, but it does mean that unless someone who IS experiancing the problems can report them and test the fixes the developers have no way to know there are problems and fix them
after all, do you thingk the developers would release a kernel that was crashing their boxes? the fact that it gets released in a fair indication that there are no major problems that they know about.
Kernel release status Posted Feb 16, 2006 10:15 UTC (Thu) by ewan (subscriber, #5533) [Link] There is, of course, nothing that keeps you from using RedHat's kernelsources on your Debian box, nor indeed anything that stops Debian making binary packages from them.
Kernel release status Posted Feb 16, 2006 17:11 UTC (Thu) by maks (subscriber, #32426) [Link] > They're moving way too fast, shoving new features down our throats so> quickly that there's no time to shake them out. They're forcing all of us > to be beta-testers. They _need_ to go back to the old system of leaving > the code alone and letting it stabilize, instead of just waving their > hands in the air and expecting 'the distros' to fix it.
every distro 2.4 kernel grew to a different biest,
the current development is working great. you quickly get hardware support for newer hardware. bugs gets fixed much quicker. there is a staging area -mm. the stable release series sorts out problem that only get detected due to greater user base.
> The Debian kernel team, at the very least, seems to be mostly just
todays vanilla kernel are very feature full, no need to carry around historic patch bags like an httpd in kernel space.
the debian kernel team is backporting fixes to the 2 old kernel 2.6.8. as long as your hardware is supported you still have the advantage of stable releases of course if you mix your releases you are on your own.
you can never have a big enough qa lab, if you find bugs please report them.
Kernel release status Posted Feb 16, 2006 23:19 UTC (Thu) by xorbe (subscriber, #3165) [Link] I've had 2.6.16-* from Mandriva lock up a couple times. I recently upgraded from 2.6.12 or .13 -- been a long time since I've had freezes!
Kernel release status Posted Feb 16, 2006 11:02 UTC (Thu) by nix (subscriber, #2304) [Link] For the opposite story, my largest server is currently suffering from RAM problems so severe that it can't md5sum a 100Mb file twice and get the same answer.
But despite this, Linux is *still running*. There's only been one oops in two weeks, and that was nonlethal. (Of course the system isn't much *use* for anything with this level of unreliability, but I can't see anything generally wrong with 2.6.15 from here.)
Of course, I'm not using ACPI. I could --- the machine is capable of it --- but avoiding anything that requires putting bytecode interpreters into the kernel just seems the right general approach. :)
Kernel release status Posted Feb 17, 2006 3:22 UTC (Fri) by roelofs (guest, #2599) [Link] For the opposite story, my largest server is currently suffering from RAM problems so severe that it can't md5sum a 100Mb file twice and get the same answer.Ugh, sounds like you need memtest86 followed by Rik's (van Riel?) BadRAM patch to work around the bad bits/bytes. I found such a problem about halfway into the upper 512MB of RAM on my main box; that patch saved a DIMM that would otherwise have been rendered useless by just two bad bits inside a single byte. Very handy. Greg
Kernel release status Posted Feb 19, 2006 8:22 UTC (Sun) by nix (subscriber, #2304) [Link] I wish. memtest86 and memtest86+ both found no faults, and it's hard to use BadRAM without that, given the obscurity of the input arguments if you don't know the failing addresses. (This is odd, given that the fault was severe enough for md5sum to spot it!)
We isolated the bad DIMM and replaced it: the machine was in warranty so the cost (to me ;) ) was zero.
(Damn cheap refurbished memory, *grumble*; new SDRAM is hard to find these days)
|
|||||||||||||