> Have you reopened it already? Can you provide bug number? BUG 2080. I reopened, got told that that is completely different issue, then encountered exactly the same issue on supposedly fixed kernel, so reopened again.
> Any other statements like > "there are many bugs", "this kernel is unstable" are just not > specific enough for me to deal with. That's why I wanted to provide a way to reproduce the problem, I would imagine that overnight stresstest would already be a part of your internal QA. This got through our own QA probably because we were running only 'stress' app, only when we added parallel bonnie+ ( which we did, because production machines that were crashing all had significant IO on them as common thing ). > If there are bugs, they need to be reported and fixed, and we, > OpenVZ team, partly rely on you, our users. We do have internal QA > but can't possibly test all the use cases and scenarios. > > Specifically, we rely on having bug reports from you, with full > kernel logs (see http://wiki.openvz.org/Remote_console_setup), test > cases (as specific and reproducible as possible), and ideally your > ability to test patches that developers provide and report your > results back to bugzilla. > > We treat bug reports very seriously, and we do our best to reproduce > your bugs locally and fix them. Again, please be specific and refer Thats very nice and correct, can you please tell me if the issue I can see here has been reproduced and is too hard to fix, or maybe it's not reproducible, and then, how can I help in reproducing them. As I said, from my point of view, the issue is trivially reproducible, results in crashes manifesting themselves in few different ways, so I assume that means multiple different bugs, or something more fundamental. best regards, Eyck -- Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 Total Existance Failure _______________________________________________ Users mailing list [email protected] https://openvz.org/mailman/listinfo/users
