Comment 19 for bug 1355044

Revision history for this message
Matt (mdinger-bugzilla) wrote :

Currently, the mapping from upstream to ubuntu doesn't seem to matter because christopher sent you to check upstream. Once he sees what the fix is, he can determine where it maps to the ubuntu kernel, if it actually does. This is probably the link you want:

https://wiki.ubuntu.com/Kernel/KernelBisection#Reverse_commit_bisecting_upstream_kernel_versions

Basically you clone the linux repository, make sure you can build the kernel (which takes a long time), and then you can start bisecting. The bisect command has you mark a `good` and a `bad` commit. It will proceed to check out the minimum number of commits so you can examine each to see where the bug started. Note: you don't need to use bisect. It's just a convenience tool.

Without bisect, follow these steps until you know which commit produced the bug:
1. Note a good and bad commit number
2. Checkout the commit half-way between the good and bad commit
3. Compile the source
4. Install the kernel
5. Test the kernel
6. If bad, mark as bad. If good, mark as good.
7. Go back to step 2

So:
`git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git` to clone the repository
configure and build the kernel to make sure it builds
`git checkout 09f95d5` to checkout the last broken commit which is hopefully this one
`make clean` and build and test the kernel (hopefully the kernel doesn't work)
`git checkout 0c78a44` to checkout the first working commit
build and test the kernel

You can use something like gitg (https://wiki.gnome.org/Apps/Gitg) to visualize the git history. It may help.

If the second commit doesn't fix it...bisecting will take much longer. But that should be the fix.