On Sun, Mar 23, 2014 at 8:53 AM, Fengguang Wu <fengguang.wu@xxxxxxxxx> wrote: > Hi Bjorn, > > On Fri, Mar 21, 2014 at 12:42:33PM -0600, Bjorn Helgaas wrote: >> On Thu, Mar 20, 2014 at 8:09 PM, Fengguang Wu <fengguang.wu@xxxxxxxxx> wrote: >> > // CC Stephane for RAPL related bug >> > >> > Bjorn, sorry this bug report is mis-titled. The only new bug that show >> > up in aa11fc58dc is on rapl_pmu_init. And it shows up only 1 time, so >> > it's hard to reproduce and the bisect is likely not accurate. I'll >> > retry the bisect with more repeat count. Sorry for the disturbing! >> >> This testing is potentially very useful, but only if we don't have >> many false positives. I spent a lot of time trying to figure this >> out, and it turned out not to be a problem at all. > > I'm sorry for the false report! I'll be careful and improve the > process. Currently there are many false positives in our internal > boot error bisects. And we rely on human reviews to select good > bisects out of the noises. In this case both the script and me made > mistakes, which lead to the wrong report. > >> As a procedural question, can you help me figure out how to handle a >> report like this? What I *hoped* for would be: >> >> - the config you used > > Yes. > >> - the dmesg log from the newest good commit > > I'll attach it if the first bad commit's parent commit(s) has some > noise errors. In this case it may help decide whether the bisect is > wrong: in some cases one bug will hide another one; or the bug message > may change from one to the other. > >> - the dmesg log from the oldest bad commit (the one you bisected to) > > OK, I've fixed the script to attach it (rather than attaching the > branch HEAD's dmesg). > >> - maybe a hint about how I can reproduce the problem, e.g., the qemu >> config I need > > OK, fixed the reporting script to include the QEMU commands for > reproducing the problem. > >> You did supply the config, which is good. But you only supplied one >> dmesg log, and it doesn't seem to be from the oldest bad commit. In >> fact, it seems to be from some commit that isn't actually in either >> Linus' tree or in linux-next. So I don't know what the connection is >> with the bad commit. > > Sorry the dmesg file is from the internal merge-and-testing branch's > HEAD -- where the bisect starts. I'll attach the first bad commit's > dmesg instead. > >> What should I do to try to debug a report like this? Where should I start? > > Thank you very much for the suggestions! Excellent, thanks! I think these will make it much easier to figure out where to start. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
