Lines Matching refs:that

11 - Finding patch that caused a bug
20 not confident in doing that please report the bug to your distribution vendor
25 MAINTAINERS for who that is for the subsystem you have worked on.
32 Often this is caused by udev. Check that first before blaming it on the
35 Finding patch that caused a bug
62         . All the kernel tar files from a revision that worked to the
63           revision that doesn't
67         . Rebuild a revision that you believe works, install, and verify that.
70           you know that 1.3.69 does.  Pick a kernel in the middle and build
71           that, like 1.3.50.  Build & test; if it works, pick the mid point
73         . You'll narrow it down to the kernel that introduced the bug.  You
78           - Copy kernel that works into "test".  Let's say that 3.62 works,
80             up with a list of directories that changed.  For each of those
92                 And then rebuild and retest.  Assuming that all related
97                 found in my case that they were self explanatory - you may
98                 or may not want to give up when that happens.
103             hoping that the changes in that file are self contained.
108             a merged file that has
122             And then walk through that file, one routine at a time and
130             that makes the difference.
132 Finally, you take all the info that you have, kernel revisions, bug
134 that off to whomever you believe is the maintainer of that section.
143 because Linux snapshots will let you do this - something that you can't
201 And use GDB to translate that to human-readable form:
226 this shows the problem in the :jbd: module. You can load that module in gdb
237 initialised and not set before use etc. To see the values that get assigned