I did the debugging work because I thought you (or upstream) might find it useful. Plenty of lockups have been reported but not many where it's possible to observe a faulty kernel or hardware state in detail.
Specifically, because of the clues in how the kernel or hardware state was broken and X server restart didn't recover it, I though you or upstream developers would find it useful. But it appears that was a mistake since you weren't interested in analysis, just whether running Karmic for a month locks up less often. (Running it for a day would not be enough). In other words, if I'd just reported it locking up, your response would have been exactly the same: try Karmic, see if it's more reliable. I'm not sure what response you were waiting for, other than 'I ran Karmic and don't get (as many) lockups'. Instead I turned off DRI entirely (on Jaunty), and I get far fewer lockups but have still had one, unfortunately. Presumably the one I had subsequently was a different kind, as the one in this report depends on DRI. ==> So, I have a question: If I do experience lockups when I eventually move to Karmic and re-enable DRI, and it's not a complete system freeze so possible to debug like in this report, should I spend the hours doing that or is it not useful here? Thanks! Btw, why is the new status Invalid and not Closed? This report may be useful to someone else who comes searching in future, especially if the problem reappears, and Invalid bugs tend to be skipped over when searching. -- [i945GM] X server gets stuck in loop waiting on DRI, reads mouse events but ignores all socket I/O hence appears frozen https://bugs.launchpad.net/bugs/398968 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
