On Sun, 13 Sep 2015 14:09:21 -0300, Lucas Tanure said:
I would like some tips about how debug a issue with linux-next. I'm trying to find things to do in kernel, and the first thing is boot the linux-next tree.
How I can find the commit that create the problem, since every commit that I tested I got black screen ? Whats the best way to debug this kind of issue ?
Since you obviously had a non-linux-next kernel that *did* boot, 'git bisect' is the fastest way to find the buggy commit. The best part is that it requires almost no actual understanding of the code. General scheme for using git bisect, even if you have *no* idea what the problem is: Say you know that a 4.0 kernel works OK. You then do: git bisect start get bisect bad next-201150910 (or whatever the earliest known-bad is) git bisect good v4.0 (Round stable releases like 4.0.9 to the base) Repeat the following: Build the kernel. Boot it. Reboot to a known good kernel if needed. If it was good, use 'git bisect good' If it died, 'git bisect bad'. end repeat until it tells you the bad commit. (It won't take long - going from 4.0 to current linux-next will probably take 11 to 13 times around). And it's simple enough to do that most of the time I have to bisect something, I'll do it on my laptop while watching something on Netflix.... *** NOTE *** * Avoid the temptation to try to bisect between two next-2015... tags * because you know the problem commit is between two tags a week apart. * Due to the way that linux-next is built, this *won't* work. This is * probably the single biggest cause of failure to bisect a problem in * linux-next *** END NOTE Since you know the problem is i915 related, you can speed the process up even more by doing git bisect start -- drivers/gpu/drm/i915 which instead of considering *all* commits, will only bisect across commits that touch that part of the source tree...