Comment 9 for bug 227882

In the end I resorted to experiment myself with vanilla 2.6.25.9.

Spent a night compiling it and the nvidia stuff.

It works without any problems and it is stable.

Hence:

- either 2.6.24 was a very poor choice for Hardy because the upstream 2.6.24 is the cause of the random hard lockups;
- or the upstream 2.6.24 is fine and the ubuntu patches break it.

In either case I believe that this situation is getting weird:

1) Everybody at this point knows that the hardy kernels cause random freezes to many users;
2) Everybody knows that these freezes are subtle as they may happen every few hours, so after having set up a system it is impossible to say for sure whether it is affected by the bug or not without many hours of testing
3) Everybody is just avoiding upgrades from gutsy to hardy just because of that. Note that even if the risk of being hit by the bug is low (say 1%) there is a multiplicative effect here - 50% of potential users will stay away from hardy just because of the risk, just as in insurances where if some accident statistically hits 1% of population, more than 50% decides to make an insurance.
4) The solution of the problem is known since vanilla 2.6.25 fixes the bug.
5) But Ubuntu in 2 months (33% of the release cycle time of hardy itself) has deliberately released no fix since
- it is forbidden by the policy to release 2.6.25 for hardy
- no one seems to know how to patch 2.6.24 to make it behave correctly like 2.6.25

So the policy seems to work very very bad here: backporting the fix to 2.6.24 seems much much more troublesome than releasing a 2.6.25.
Looks like the sense of "long term support" is that the policy will enable support to arrive only in the long term.

The only solution to this apparent deadlock is that some Ubuntu kernel developer feels like to autonomously deliver a 2.6.25 with ubuntu modules and restricted drivers via the ppa channel, so we can bypass the policy and have a fixed and reasonably maintained kernel for hardy.