Linux 3.13.0 x KDE git

[Duncan]

Dâniel Fraga posted on Sat, 25 Jan 2014 06:38:40 -0200 as excerpted:

> I upgraded my Linux kernel from 3.12.0 to 3.13.0 and now when I enter in
> the KDE desktop, the mouse works for a few seconds and then gets stuck.
> 
> Going back to 3.12.0 kernel "solves" the problem, so something
> has changed in Linux 3.13.0 to cause this.
> 
> Is there some way to debug this?

There is and I've successfully used this method to pin down kernel 
problems myself, but it takes time and patience, and the fact that you're 
asking this means it's unlikely to be "easy", and depending on your tech 
level, it might be effectively impossible.  Tho given that you could pin 
it to a problem between kernels 3.12.0 and 3.13.0 indicates at least the 
latter ("impossible") is unlikely to apply in your case. =:^)

There's a lot about your system you don't mention, that might have been 
helpful had you posted it.  Like what distro, where you get your kernel 
and whether you know how to configure and build it yourself, or whether 
you simply downloaded and installed a prebuilt kernel update.  But 
there's some assumptions that can be made based on what you /did/ post. 
=:^)

We can assume that either you're on a relatively fast updating distro, or 
did the kernel update yourself, reasonably likely from mainline kernel 
sources, which will already make things MUCH easier since you're more 
than half way there already.

Also, the subject mentions KDE git, but it's unclear from the rest of 
your post exactly what kde has to do with it other than it's presumably 
your desktop environment of choice.  Further, that it's git hints at at 
least some git knowledge, but the fact that you apparently don't know of 
git bisect (which is what I'm about to explain) hints you don't know that 
much about git.

If you're already using git (and the reference to kde git wasn't simply 
to something like gentoo's automated git builds, which as a gentooer and 
kder I use myself, but that fact alone doesn't mean I actually know much 
about git) and are familiar with git checkout, pull, etc, then again, 
you're well on your way.

And if you're BOTH building your own kernels and using git, then you're 
almost there!

OK, the idea is this.  Given a kernel that works and a kernel that 
doesn't, by definition establishes a fixed domain of candidate problem 
commits, the series of commits that together turned the working kernel 
into the non-working kernel.  With that knowledge, even with relatively 
little or no actual coding skills, it's possible to turn the process of 
finding the culprit commit into a mechanical bisection, dividing the 
remaining problem space (in the form of individual git commits) in half 
at each step and testing to see which half the bug is in, then 
recursively testing that half... until ideally, you pin the problem to a 
single culprit commit, with anything previous to that working as the 
problem commit isn't included yet, and anything beyond that not working, 
because the code now contains the problem commit.

The tool used to do this is git itself -- specifically, the git bisect 
command.

Assuming you have git already installed, if you don't already have a git 
kernel clone, you create one.  You can then read about git bisect using 
git bisect --help, for the details, but as an overview, the process looks 
something like this:

git bisect start <bad> <good>

Here, that would be:

git bisect start v3.13.0 v3.12.0

Git will churn a bit, figuring out a merge commit somewhere close to half 
way between the two given kernels and checking it out to test-build, 
telling you about how many steps you have left to pin down the problem.

You then build and install that kernel, and boot it to test.  Then you 
tell git whether the problem was there or not using

git bisect bad

or

git bisect good

Either way, git uses that to figure out which half the bad commit was in 
and recursively splits that half in half, finding another merge commit 
and checking it out for another test-build, with another estimate on 
number of steps.

This process repeats until the culprit merge commit is known, after which 
git bisect continues down to the individual commit.

One note.  During the bisect, git will sometimes leave you at commits 
that appear to be outside the range you gave it, say perhaps v3.11-
rc5-00xxx-gyyyyyyyy or some such.  That's normally because the person 
submitting that patch was basing it on the then in testing 3.11-rc 
kernel, as 3.12 wasn't out at the time of patch development.  So don't 
pay /too/ much attention to the version numbers git bisect gives you.  
No, they don't always look like they're in the expected range.  Yes, 
barring a huge bug in git, they actually are in range and only got final 
merge to mainline after the last commit you told git was good.

At any point in the process, you can git bisect visualize to see the logs 
for the remaining commits.  Obviously this doesn't make much sense until 
you get down to perhaps a hundred commits or so left, but once you do, 
it's interesting to take a guess at where the problem might be and see if 
you're right, as the process continues.

You can also git bisect log, to see the log of good/bad reports to this 
point, and if you like, redirect that to a file for later replay using 
git bisect replay if you need to.  With a copy of the bisect log stored 
somewhere, you can do a git bisect reset to leave the bisect process 
temporarily if desired, say to git pull and see if the problem still 
exists in the latest kernel head.  Then replay to get back where you were 
and continue the bisect.

If a commit comes up that has other problems on your machine, such that 
you can't get it to boot to test the mouse problem you're trying to 
bisect, you can use git bisect skip, or you can manually checkout another 
commit to test if you like, tho the manual checkout switching during 
bisect is advanced functionality that non-devs (like me) probably don't 
make much use of.

Meanwhile, it should be obvious that if you can pin down the problem a 
bit more before the bisect it'll help.  Additionally, if git bisect is 
simply beyond what you're prepared to do, you can still pin it down 
further using more conventional methods.  You know the problem is between 
3.12.0 and 3.13,0 but what about the latest stable 3.12.x release, which 
will have a few of the commits that were thought most stable from the 
3.13 series backported to 3.12?  And what about the 3.13-rcs?  Most of 
the raw development gets merged in the nominally 2-week commit window 
between the .0 release of the last version and the rc1 release of the 
current testing version, so testing rc1 can be quite useful too, since if 
it's bad, the problem was introduced in the raw development commit phase 
and simply never caught and fixed, while if rc1 is good, the problem was 
introduced later during the stabilization period, with a commit that was 
meant to fix other breakage from the raw development period, but 
obviously ended up breaking something for you, as well, and that's a much 
more interesting case.

So before I started the actual bisect or if you decide not to actually 
try a bisect, I think I'd try building and testing 3.13-rc1 and see if 
the problem is there.  If it is, you shortened your bisect testing by a 
few iterations (or narrowed down the reported range if you don't do the 
bisect yourself).  If not, then you have a much more interesting bug to 
report.  Similarly, if a later 3.12.x stable series release has the 
problem as well, you have a REAL interesting bug, because those commits 
are hand-picked to backport as the most stable, with real fixes for real 
problems, and if they're breaking things, THE DEVS WILL WANT TO KNOW 
ABOUT IT!

The git bisect --help manpage has many more hints.  For instance, if you 
can read code at all or are otherwise familiar enough with the kernel to 
be quite sure you know for sure what kernel sources subdir is involved, 
you can tell git bisect start about that as well, and it'll narrow the 
bisect to only commits that touch that code.  However, I'm not a coder, 
and while I've successfully used git bisect to pin down and ultimately 
report a number of kernel bugs, I've only felt confident enough that I 
knew the general kernel subdirs that might be at fault just once -- tho 
that was the last bug I bisected, so perhaps even if I'm not a dev I'm 
getting familiar enough with the kernel sources layout in general to do 
this more often.  I can hope, anyway. =:^)

So that's git bisect.  As I said, it takes some patience and isn't 
exactly easy, even for people who are already building their own kernels 
and using git.  But it's a way for non-coders to never-the-less help fix 
their own bug reports, by narrowing down the problem to a specific git 
commit, and as such, I know I've reported and helped much more to fix a 
number of kernel bugs I'd have either never reported in the first place, 
or would have been totally dependent on the kernel devs to figure out 
where the problem was, were git bisect not available.  So I'm glad it's 
there! =:^)

As for bug reporting, most kernel devs seem to prefer posting to whatever 
specific list (say the btrfs list for btrfs bugs, used as an example here 
since I'm testing btrfs and am in fact subscribed and a regular list 
poster there myself) applies -- there's a list of kernel components and 
where to report bugs associated with them in the kernel sources 
Documentation directory.

But here, I actually prefer to use the kernel bugzilla, and that's the 
way I've reported and gotten fixed all the kernel bugs I've reported, 
since I'm familiar with bugzilla from using it for bug reports to other 
projects (including kde).

https://bugzilla.kernel.org

If you're interested, here's a list of the bugs I reported or CCed on.  
You can see how they tracked to ultimate resolution, and how git bisect 
helped on some of them (and didn't on one, IIRC, as it lead to a dead end 
in something entirely unrelated due to the bug being hard to reproduce so 
I could never say for sure whether a git bisect good was accurate, tho I 
knew the bads were definitely bad).

https://bugzilla.kernel.org/buglist.cgi?quicksearch=ALL%201i5t5.duncan%40cox.net

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.