Thanks Peter for the in depth explanation. I was actually just reading a very detailed blog post by a person bug hunting in fedora 20 . . . the blog post could be considered a book in of its self, and wow yes, lots of learning to do before I can achieve the same myself.
On Sun, Jul 12, 2015 at 2:16 PM, Peter Hurley <[email protected]> wrote: > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
