3

Let's say you're trying to find the cause of a bug between 3.11.0 and 3.12.0. The bug is really difficult to catch, because it may or may not manifest itself over several days of regular workload uptime.

You mark 3.11.0 good. You mark 3.12.0 bad. Start bisect.

Then, running on the bisect patch, the kernel fails in some other significant way that makes catching the original bug maybe impossible. For example with some constant drm graphics corruption it may be impossible to replicate the several days of uptime needed to try to catch the original bug.

So what do you do? Can't really mark this patch "good" right, so the logical option would only be "bad".

closed as off-topic by Braiam, Anthon, slm Oct 17 '14 at 5:52

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question has been posted on multiple sites. Cross-posting is strongly discouraged; see the help center and community FAQ for more information." – Anthon, slm

  • Maybe disable the part of the kernel that is causing the corruption if possible, e.g. run without X? – Faheem Mitha Jul 20 '14 at 13:09
  • I don't see how that can be done. The bug is probably related to graphics stack and X activity specifically. I don't know any other way to manifest it other than just doing my regular daily work, heavy browser work, video calls etc. – lkraav Jul 20 '14 at 13:56
  • Ok, just a suggestion. – Faheem Mitha Jul 20 '14 at 14:06
  • Note that while your question is on-topic here, there is a lot more git expertise on Stack Overflow, and all version control questions are considered on-topic there. Do not repost; if you wish, your question can be migrated to SO my a moderator: use the “flag” button to request it. – Gilles Jul 20 '14 at 22:46
  • I don't know @Gilles.. This could indeed be a general software development question, with the kernel used as just as an example. I guess we could try to move it over, since USC isn't getting results anyway. – lkraav Jul 22 '14 at 19:02