Linux 3.13.0 x KDE git
1i5t5.duncan at cox.net
Sat Jan 25 10:31:17 GMT 2014
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
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
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
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
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
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
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).
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).
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.
More info: http://www.kde.org/faq.html.
More information about the kde