Eric Lee / linux-smarc-t335x-v3.2

Download as
Browse Code ยป

Commit d81919c9c22466183115f83645128da4c2482fcd

Authored by Clemens Koller
Committed by Adrian Bunk
1 parent 06c93e8757
Exists in master and in 4 other branches v3.2_AM335xPSP_04.06.00.11, v3.2_NEWT335xPSP_04.06.00.11, v3.2_SBC_SMARTMEN, v3.2_SMARCT335xPSP_04.06.00.11

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>

Showing 1 changed file with 11 additions and 11 deletions Side-by-side Diff

Documentation/BUG-HUNTING
Diff comments   View file @ d81919c
... ... @@ -53,7 +53,7 @@
53 53  
54 54 [Sat Mar 2 10:32:33 PST 1996 KERNEL_BUG-HOWTO lm@sgi.com (Larry McVoy)]
55 55  
56   -This is how to track down a bug if you know nothing about kernel hacking.
  56 +This is how to track down a bug if you know nothing about kernel hacking.
57 57 It's a brute force approach but it works pretty well.
58 58  
59 59 You need:
60 60  
... ... @@ -66,12 +66,12 @@
66 66  
67 67 . Rebuild a revision that you believe works, install, and verify that.
68 68 . Do a binary search over the kernels to figure out which one
69   - introduced the bug. I.e., suppose 1.3.28 didn't have the bug, but
  69 + introduced the bug. I.e., suppose 1.3.28 didn't have the bug, but
70 70 you know that 1.3.69 does. Pick a kernel in the middle and build
71 71 that, like 1.3.50. Build & test; if it works, pick the mid point
72 72 between .50 and .69, else the mid point between .28 and .50.
73 73 . You'll narrow it down to the kernel that introduced the bug. You
74   - can probably do better than this but it gets tricky.
  74 + can probably do better than this but it gets tricky.
75 75  
76 76 . Narrow it down to a subdirectory
77 77  
78 78  
79 79  
80 80  
81 81  
... ... @@ -81,27 +81,27 @@
81 81 directories:
82 82  
83 83 Copy the non-working directory next to the working directory
84   - as "dir.63".
  84 + as "dir.63".
85 85 One directory at time, try moving the working directory to
86   - "dir.62" and mv dir.63 dir"time, try
  86 + "dir.62" and mv dir.63 dir"time, try
87 87  
88 88 mv dir dir.62
89 89 mv dir.63 dir
90 90 find dir -name '*.[oa]' -print | xargs rm -f
91 91  
92 92 And then rebuild and retest. Assuming that all related
93   - changes were contained in the sub directory, this should
94   - isolate the change to a directory.
  93 + changes were contained in the sub directory, this should
  94 + isolate the change to a directory.
95 95  
96 96 Problems: changes in header files may have occurred; I've
97   - found in my case that they were self explanatory - you may
  97 + found in my case that they were self explanatory - you may
98 98 or may not want to give up when that happens.
99 99  
100 100 . Narrow it down to a file
101 101  
102 102 - You can apply the same technique to each file in the directory,
103   - hoping that the changes in that file are self contained.
104   -
  103 + hoping that the changes in that file are self contained.
  104 +
105 105 . Narrow it down to a routine
106 106  
107 107 - You can take the old file and the new file and manually create
... ... @@ -130,7 +130,7 @@
130 130 that makes the difference.
131 131  
132 132 Finally, you take all the info that you have, kernel revisions, bug
133   -description, the extent to which you have narrowed it down, and pass
  133 +description, the extent to which you have narrowed it down, and pass
134 134 that off to whomever you believe is the maintainer of that section.
135 135 A post to linux.dev.kernel isn't such a bad idea if you've done some
136 136 work to narrow it down.