Comment 277 for bug 204996

Chris Coulson wrote:
> sergio - It could very well be the source of Tom's problem but there is
> no way of knowing with such little information.
Chris, you are right. Indeed it could. But it wouldn't be good news. It
would mean that all of a sudden, after having had many kernels
performing stably on most hardware we get into a 2.6.24 having many
different bugs in many different subsystems, /all/ resulting in hard
lockups rather than in more disciplinated kernel oopses.

Furthermore, bugs in drivers have typically been rapidly spotted and
fixed, since driver code is generally modularised and finding the bug
location is generally as easy as preventing the loading of some modules.
Conversely, the pattern that I am seeing here by reading most of the
messages in the various threads is the following:
1) I have the freeze issue
2) I have tried this and this (typically removing some driver or even
some userland software) and I do not have it anymore, eureka: it is
<pick something among Nvidia, Ati, a wireless driver, even Firefox 3, etc>
3) oops sorry, instead of freezing after 30' my system did after 6 hours.
> Just because you see
> lock-ups without wireless doesn't mean that other peoples lock-ups can't
> be caused by their wireless.
Yes, but due to the above, we need to kindly urge bug reporters to open
/new/ bugs if they believe that they have identified a particular
subsystem causing the bug.
Surely, I did that in the wrong way and I apologize.
Even more important we need to make sure that bug reporters do not post
1) and 2) above, forgetting to post 3) in case the bug still manifests.

Or otherwise we can open a new bug "Linux kernel 2.6.24 lockup, do not
post here unless you are experiencing the bug even without ATI, NVIDIA,
wireless and SATA"
> As already pointed out many times above,
> the people posting to this bug report possibly have completely different
> bugs, all with the same symptom. Just because you all see lock-ups does
> not mean they are being caused by exactly the same bug.
>
> There are so many different combinations of hardware in this bug report
> now that it has become virtually impossible to follow. This bug is fixed
> in Intrepid for the original reporter (hence why it is marked as being
> tracked in Intrepid).
Sorry, I still believe that this is very wrong. If the bug, that was
originally opened for hardy, is fixed in intrepid for the original
reporter, then there should be an open hardy tracked bug with the notice
that it is fixed in intrepid, not a fix-released intrepid tracked bug.

Alternatively, by absurd, if all hardy bugs were found to be fixed in
intrepid, we could nicely say "hurrah, hardy is the perfect
distribution: it has no open tracked bug at all".

Note that traking the bug only for intrepid means that if you look for
some bug concerning freezes on hardy you do not find this bug.
Also if one wanted to collect statistics and count hardy bugs, he would
not count this one.

> It isn't fixed in Hardy because it is very
> difficult to establish exactly what commit fixes the bug for the
> original reporter.
>
The question is if it is worth trying to establish it at all. If the
bug manifests randomly every 4-6 hours, every single test may require a
whole day. A bisections involving 16 steps requires a fortnight.
Indeed, since the original report already 4 months have passed with no
success. Testing whether a backported intrepid kernel breaks something
on hardy would probably be a much faster and more useful effort.

Sergio