Comments on: 2.6 Suckiness

By: Anonymous

Anonymous — Thu, 13 Apr 2006 06:42:10 +0000

If you want to help track down the bug, try git-bisect on the kernel. Install the package “git-core”, then just “git clone http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git“, build/test, “git bisect bad” if it doesn’t work, then “git bisect good v2.6.13″, then it will continue to hand you kernels to build and test (with you saying “git bisect good” or “git bisect bad”) until it tells you exactly the commit at fault. You can also use “git bisect visualize” to see your progress.

By: Guus Houtzager

Guus Houtzager — Mon, 27 Feb 2006 15:47:58 +0000

Hi,

I had the same problem with 2.6.15.4 (standard Debian Sarge kernel 2.6.8-2 works fine), compiling in the other Promise controller aswell with the FORCE option solved it:
CONFIG_BLK_DEV_PDC202XX_OLD=y
CONFIG_PDC202XX_BURST=y
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_PDC202XX_FORCE=y

Hth,

Guus

By: Ian McDonald

Ian McDonald — Mon, 20 Feb 2006 04:03:10 +0000

Well this is certainly an interesting one and something I think about a bit too. Some random points:
- from 2.6.12 I think you need udev really and what’s worse if you try and go back to an earlier kernel you can’t even boot and you often need to use a rescue disk to fix your filesystem
- Linus has recognised that kernel process sux and now the first two weeks of a new kernel are for new features and after that it is supposed to be bug fixes only. This in itself should help substantially in my opinion as you don’t get a major change days before a kernel release
- The stable tree 2.6.x.y is getting a lot of fixes in it. This means either that 1) We are catching up with past bugs or 2) When people fix bugs in development kernels they are backporting it. Probably a mixture of both
- It is hard to get good kernels out there when you don’t have testers testing development code. However I think Linux could really do with some better automated testing.
- I think you should be able to use old include headers. Linux takes great pains to preseve this compatiability
- Part of the problem (a large part IMHO) is that Linux is struggling with growth on a monolithic kernel. As a kernel developer (UML, TCP, DCCP) I wish it was a microkernel design so that my bad code doesn’t kill everybody elses code
- It is bloody hard to debug in the kernel so hard to test things and fix them at times. I have to resort to printk’s as I don’t have a serial console, UML is too unstable and involves invasive changes. qemu looks OK in theory but hard work getting a filesystem going for it…. Any pointers from anybody I would appreciate on this…

By: Aristotle Pagaltzis

Aristotle Pagaltzis — Sat, 18 Feb 2006 10:19:11 +0000

Matt: the kernel people apparently feel that it’s not really their responsibility to stabilise the kernels users run, it’s the distributors’. Only the “sucker trees” AKA 2.6.x.y get any stabilisation love.

It blows, if you ask me.

By: Foolab.org - Mohammed Sameer's

Foolab.org - Mohammed Sameer's — Sat, 18 Feb 2006 02:18:35 +0000

Linux 2.6 SUX!

First, I know that I should STFU because I’m not going to write a patch to fix it but I can’t as I’m not a kernel developer and the knowledge I have about the kernel development is the same as the knowledge I have about T.V internals