Bug report number for "causes random lockups"

This is still anecdotal, but I have been seeing frequent freezes on my laptop (though not the
desktop), and only after reading this thread does it occur to me that the hardy kernel could
be responsible.  There were occasional freezes earlier, related to the wireless card, but it's
far more frequent now.  

I agree that the Ubuntu kernel developers need some more resource.  I struggled for quite a
long time with a different freeze problem on Gutsy and Hardy kernels (2.6.22 and 2.6.24) which
involved a "nobody cared" message on a shared IRQ, followed by a lockup of the devices using
that IRQ.  I bypassed this by the kernel boot parameters "all_generic_ide irqpoll" which
doesn't seem to have hit performance noticeably, but it wasted quite a lot of time when I was
setting up a new PC built specifically for Ubuntu.

Also, suspend/hibernate took some time to get working, but that's due to lack of a really good
configuration wizard that will figure out the various options required to make it work.  And
it's broken again for some reason that I can't figure out...  

I really like Ubuntu but I hope that stability and bug-fixing can be given more attention over
new features.  I don't really need new features but would like a few things to work better.

I realise that it is still a generalisation and that to count the actual number of systems
showing a the random lockups would be extremely difficult. And I agree that it is wrong to try
to compute the goodness of a distribution from the loudness of the yells or the prises.

Also I do not want to diminish ubuntu in any way, since it has generally done an excellent
job.

However, the bug reports surely tell us that the number of affected systems is > 0 and that
the regression exists.  

It is clear that regressions can happen. But in some sense you might get a subtle feeling that
there is regression and regression and that one causing the system to suddendly lock and some
of your data to disappear (because you had a virtual machine on at that moment and that didn't
know anything of how to deal with the freeze) is particularly nasty. Also, and more
annoyingly, having linux doing this sort of things tends to rise a sense of revenge in all
your friends who were getting blue screens of death on ME.

But in my opinion the real point here is how to solve the issue as fast as possible and create
conditions so that similar situations do not happen again.  Because the problem is not the
bug, but the management:

1) The bug was known since before hardy release
2) A solution has been known for more than 1 months, but not delivered to anybody
3) The bug appears to be marked as "fix-released". And this is a full acknowledgement of the
bug existence, but is also a funny wording, because the fix was not released
4) And most important, there are many users, like myself, that are now in need to run on
custom kernels that won't likely get any security fix because it takes hours to compile a
kernel.

So, I am only underlining the fact that the policies are not working well here and that the
most notable consequence is a hard-to-quantify but surely non-null rise in the number of
people running unsupported custom kernels on the long term support distro, which is sort of
contradiction.

If 2.6.25 is known to fix issues to some, why not just releasing it in addition (if not in
substitution) to 2.6.24 and why not doing so early?

As a final consideration, understand that there can surely be a rise in the  number of people
involved in the ubuntu kernel.  But that it will always be extremely difficult to find people
willing to x-ray the differences between 2.6.x and the ubuntu 2.6.(x-k) to confine the changes
to backport to ununtu's 2.6.(x-k) to fix it.  Accept that this will always be seen as a most
boring thing to do.  And that most people would just prefer concentrating on making 2.6.x
applicable.



  

My anecdotal evidence is that when my printer (an HP all in one) is connected to my laptop
(USB) *while booting*, it will often freeze within the first half hour of booting.  When it's
not plugged in at book, it will work just fine, even when I plug it in later.