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 -- Linux kernel 2.6.24-12 lockup https://bugs.launchpad.net/bugs/204996 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
