2.6.25.14 kernel

2.6.21.7
Last night I recompiled the 2.6.21.7 kernel, had to do that to enable the new PCMCIA mechanism. Most of the old modules still work, just had to substitute the newly-compiled PCMCIA-bridge modules (like yenta_socket). Also had to compile the 1.0.16 ALSA drivers, as the 2.6.21.7 kernel had the 1.0.14 drivers. Also needed the squashfs 3.3 module, as the original patched kernel source has a 3.2 patch.

But, testing it, there is some kind of incompatibility. Plugging and unplugging a PCMCIA card did not generate any hotplug uevents.

So, that one is on hold.

4.1alpha5 feedback
I have just read through all the bug reports, to get an overall impression of the major problems. There is a problem with locking up -- for example, Lobster reporting the USB mouse and the system freezing after a few minutes.

Curious, that time variability, so I did some reading of changelogs...

2.6.25.12-14
Now that is interesting -- the changelog for 2.6.25.12 fixes a USB-related bug that causes "random lockups", due to shared interrupts conflicting. This is only on some hardware.

I am quite surprised (and alarmed) at how rapidly the updates are appearing for the 2.6.25.x series. The latest is 2.6.25.14.

It is Tuesday 8.55am right now. I am away from home, will drive home this afternoon and this evening build a new kernel, using 2.6.25.14 -- unless there is yet another release in the meantime!

I will build Puppy with that and you guys with crashing/lockup problem can try it out. I will do it quickly, so it will not have all the 3rd party drivers.

Posted on 5 Aug 2008, 8:51


Comments:

Posted on 5 Aug 2008, 9:22 by dogone
Perspective
Barry. You could be entering the vortex.

Seriously, it works this way. One creeps towards the latest release of a product in search of solutions to "problems". In doing so, they inevitably move from the known to the unknown. Perspective changes as one becomes dependent upon the latest fixes for the latest released. The cushion disappears and one finds himself hard up against the "state of the art".

The solution lies in moving one's point of reference backwards in time. From a release two, four or six months old, one can see both into the past and the future. And the latter makes decision making a whole heck of a lot easier.

Puppy would be just as good and just as strong living six months in the past. Let those kernel developers squash bugs on their time, not yours.

Anyway, that's what 30 years around hardware and software has taught me.


Posted on 5 Aug 2008, 14:13 by tempestuous
2.6.26.x
If you must move up, what about 2.6.26?
This would make OneLaptopPerChild owners happy, as 2.6.26 is required just to boot past the OLPC's awkward bios.
kernel.org lists 2.6.26.1 as "stable". Hopefully the USB bug is fixed there as well?


Posted on 5 Aug 2008, 19:20 by BarryK
Re: 2.6.26.x
My thinking is that going up to 2.6.26.x is doing what dogone fears. However, as I understand it, the 2.6.25.x releases are restricted to essential bug fixes, no architectural changes likely to cause a new set of problems.


Posted on 5 Aug 2008, 20:36 by prehistoric1
the edge of chaos
There's a progression here I've seen before in unrelated software systems. The 2.2 series of kernels was limited in function and downright crude, but once they worked they were remarkably stable. The 2.4 series kernels were more ambitious and took more development effort and more people. When the 2.6 series came along, I didn't move to them until 2.6.18 appeared. At the corresponding 2.4 release, original development effort had pretty well ceased.

From a distant perspective, it looks like the 2.6 series is approaching the point where development becomes unmanageable. Not only are there fundamental bugs which undermine previously stable code, the new bugs introduced are becoming remarkably subtle and taking longer to find and fix.

This makes choosing a kernel version a tough call. I wish it were as simple as dogone's six month time delay. For my own purposes, I would simplify the problem by leaving out as much as possible. This isn't really an option when you are serving a community as varied as Puppy's.
Major distributions often freeze part of the design and backport changes they consider essential, producing a custom kernel. This becomes a full-time job for a kernel maintenance team.

I generally support dogone on this. Back off from the bleeding edge. Use your judgment on what is essential and maintainable. So far, you've done better than any individual I know.


Posted on 6 Aug 2008, 8:24 by Viking Sailor
re: re: 2.6.26.x
Berry,

The 2.6.25.x kernels don't seem to be coming together very well. There have been to many changes coming to quickly. This can happen with complex software systems. I've seen it many times in my 40 Years as a software developer. ;) In fact this is one of the basic drawbacks with monolithic kernels like Linux. However, I have to agree with tempestuous, now is not the time to roll back the kernel but to push ahead and give 2.6.26.x a shot. The whole netbook explosion that is happening, (with their low end hardware) is a great fit for Puppy.

Thanks for all your efforts,

Paul



Posted on 6 Aug 2008, 8:32 by BarryK
Re: rapid kernel changes
Yeah, it is really alarming that they are already on 2.6.27rc1, yet the 2.6.25.x is still being updated with bug fixes about every 4 - 5 days.

I was just reading yesterday that Linus reckons this development model is great. he says they will never go back to the old model, where they had a stable 2.4.x and 2.5 was the development branch. So, architecturally the 2.4 did not change much, all the geekiness was going into 2.5.

Now, the geeks are putting all their bright ideas into a kernel that in a matter of weeks becomes a released version for the whole world to use.

My thinking is that if Linux was a commercial product, those guys would be severely curtailed, and forced to follow a responsible business model of development.

Perhaps this is an example of one of the fundamental flaws of open source?


Posted on 6 Aug 2008, 9:11 by Raffy
customizing
Should some people be able to "customize" a kernel (maybe "patch" is the proper word)? This could explain the rapid pace of kernel version releases - that developers are assumed as capable of fixing their customized kernel based on updates.

I recall that Tempestuous has been playing with "bleeding edge" kernels...

I second (third?) Tempestuous' suggestion to use kernel 2.6.26.x.

Cheers.


Posted on 7 Aug 2008, 6:10 by kirk
2.6.25.15
2.6.25.15 is already out.