From: Valdis.Kletnieks@vt.edu (Valdis.Kletnieks at vt.edu)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Help debugging linux-next.
Date: Sun, 13 Sep 2015 13:36:22 -0400 [thread overview]
Message-ID: <137712.1442165782@turing-police.cc.vt.edu> (raw)
In-Reply-To: <CAJyon0sgekaG=FEtzVp2q6vxzxmge+mXo+Ag_2q5+Se8VEBnfA@mail.gmail.com>
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...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150913/12646f86/attachment.bin
prev parent reply other threads:[~2015-09-13 17:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-13 17:09 Help debugging linux-next Lucas Tanure
2015-09-13 17:19 ` leo kirotawa
2015-09-13 17:24 ` Raul Piper
2015-09-13 17:33 ` Lucas Tanure
2015-09-13 17:36 ` Valdis.Kletnieks at vt.edu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=137712.1442165782@turing-police.cc.vt.edu \
--to=valdis.kletnieks@vt.edu \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).