On 07/12/2015 04:41 PM, William Hermans wrote: > /Yeah, I think the transition to linear irq domain (added at 3.18) made > cpsw/ > /a little extra flaky. Plus the new omap_8250 serial driver is not > bug-free;/ > /just found a flow control bug in the h/w last week./ > // > /I've had ssh shells go sideways on occasion, but not with that kind of/ > /regularity or effect./ > // > /Like I said, the right diagnostic method is bisecting the kernel./ > /It's going to take a while (multiple days) if several hours are required > to/ > /distinguish good from bad kernel./ > // > /Regards,/ > /Peter Hurley/ > > > Hi Peter. "bisecting the kernel" is unknown to me. As in the meaning, But I > was wondering if some sort of remote, and very verbose logging might not help > ? Currently I'm in the process of reading / learning advanced Linux > programming, and have all these crazy ideas of what we could do. Just not > sure what to "trap" and exactly 100% how to trap it.
Linux mainline kernel source is really just a massive linear series of patches, one after the other, all tracked by git. Bisecting is a method of reducing the number of patches under test by 1/2 at each iteration to arrive at a problem commit. So, for example, let's say that I have a problem that cropped up on 4.2-rc1, but the problem wasn't happening on 4.1-rc7. I start a bisect with git: $ git bisect start v4.2-rc1 v4.1-rc7 Bisecting: 6261 revisions left to test after this (roughly 13 steps) [4570a37169d4b44d316f40b2ccc681dc93fedc7b] Merge tag 'sound-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound I build this kernel, test it, and mark it good or bad. Let's say the problem doesn't exhibit in this kernel. $ git bisect good Bisecting: 3371 revisions left to test after this (roughly 12 steps) [8d7804a2f03dbd34940fcb426450c730adf29dae] Merge tag 'driver-core-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Now I build this kernel, test it, and mark it good or bad. Let's say bad this time. $git bisect bad [3d9f96d850e4bbfae24dc9aee03033dd77c81596] Merge tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Each time, the number of commits under test are being reduced by 1/2. For a small kernel like Beaglebone this is no big deal, couple of minutes build time. For a 64-bit distro kernel, this can take several days for 14 iterations. Having a bunch of BBBs, all testing the same kernel at the same time significantly improves the confidence at each iteration that the kernel is "good" or "bad" (since obviously a problem that takes time to manifest may be mistakenly identified as "good" and then the bisect will narrow on the wrong commits). Instrumenting a problem like this is basically impossible. Regards, Peter Hurley -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
