diff options
author | Clemens Koller <clemens.koller@anagramm.de> | 2008-02-03 16:26:36 +0200 |
---|---|---|
committer | Adrian Bunk <bunk@kernel.org> | 2008-02-03 16:26:36 +0200 |
commit | d81919c9c22466183115f83645128da4c2482fcd (patch) | |
tree | 3b65a3def50cb07319a143fc79d507ad4590357e /Documentation | |
parent | 06c93e875747f3020d997220b3e7c98083acc7c3 (diff) | |
download | kernel_samsung_smdk4412-d81919c9c22466183115f83645128da4c2482fcd.zip kernel_samsung_smdk4412-d81919c9c22466183115f83645128da4c2482fcd.tar.gz kernel_samsung_smdk4412-d81919c9c22466183115f83645128da4c2482fcd.tar.bz2 |
Documentation/BUG-HUNTING whitespace cleanup
Just a little whitespace cleanup patch for Documentation/BUG-HUNTING
Signed-off-by: Clemens Koller <clemens.koller@anagramm.de>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/BUG-HUNTING | 22 |
1 files changed, 11 insertions, 11 deletions
diff --git a/Documentation/BUG-HUNTING b/Documentation/BUG-HUNTING index 35f5bd2..6c81675 100644 --- a/Documentation/BUG-HUNTING +++ b/Documentation/BUG-HUNTING @@ -53,7 +53,7 @@ Finding it the old way [Sat Mar 2 10:32:33 PST 1996 KERNEL_BUG-HOWTO lm@sgi.com (Larry McVoy)] -This is how to track down a bug if you know nothing about kernel hacking. +This is how to track down a bug if you know nothing about kernel hacking. It's a brute force approach but it works pretty well. You need: @@ -66,12 +66,12 @@ You will then do: . Rebuild a revision that you believe works, install, and verify that. . Do a binary search over the kernels to figure out which one - introduced the bug. I.e., suppose 1.3.28 didn't have the bug, but + introduced the bug. I.e., suppose 1.3.28 didn't have the bug, but you know that 1.3.69 does. Pick a kernel in the middle and build that, like 1.3.50. Build & test; if it works, pick the mid point between .50 and .69, else the mid point between .28 and .50. . You'll narrow it down to the kernel that introduced the bug. You - can probably do better than this but it gets tricky. + can probably do better than this but it gets tricky. . Narrow it down to a subdirectory @@ -81,27 +81,27 @@ You will then do: directories: Copy the non-working directory next to the working directory - as "dir.63". + as "dir.63". One directory at time, try moving the working directory to - "dir.62" and mv dir.63 dir"time, try + "dir.62" and mv dir.63 dir"time, try mv dir dir.62 mv dir.63 dir find dir -name '*.[oa]' -print | xargs rm -f And then rebuild and retest. Assuming that all related - changes were contained in the sub directory, this should - isolate the change to a directory. + changes were contained in the sub directory, this should + isolate the change to a directory. Problems: changes in header files may have occurred; I've - found in my case that they were self explanatory - you may + found in my case that they were self explanatory - you may or may not want to give up when that happens. . Narrow it down to a file - You can apply the same technique to each file in the directory, - hoping that the changes in that file are self contained. - + hoping that the changes in that file are self contained. + . Narrow it down to a routine - You can take the old file and the new file and manually create @@ -130,7 +130,7 @@ You will then do: that makes the difference. Finally, you take all the info that you have, kernel revisions, bug -description, the extent to which you have narrowed it down, and pass +description, the extent to which you have narrowed it down, and pass that off to whomever you believe is the maintainer of that section. A post to linux.dev.kernel isn't such a bad idea if you've done some work to narrow it down. |