[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.  
It's a brute force approach but it works pretty well.

ʸǤϡʤͥΥϥå󥰤ˤĤΤʤ
ɤΤ褦ˤƥХ򸫤ĤȤˤĤƤޤ
϶ȤǤϤޤȻȤˡǤ

You need:

ɬפʤΤϡ

        . A reproducible bug - it has to happen predictably (sorry)
        . All the kernel tar files from a revision that worked to the
          revision that doesn't

        ƸХ  Ƹˡ狼äƤɬפޤ
        ưΤưʤΤޤǤӥ
          ͥ tar ե
        
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 
          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.  

        ưȻפӥӥɡ
          󥹥ȡ뤷ư򸡾ڤƤ
        ͥХʥ꡼Хʥ꡼ե򥵡
        뤳ȤǤϤʤŪο͡硿ǾͤӤԤͤ
        ơͤȡ͡Ǿͤӡȷ֤ƥ
        ԤȤǤʬõȤޤˤƤɤΥӥ
        ХޤޤƤ뤫򸫤ĤƤ㤨С1.3.28 ˤ
        Х̵1.3.69 ˤϥХ뤳Ȥ狼äȤޤ
        ֡㤨 1.3.50ˤΥͥӥɡƥȤޤ
        ư硢.50.69֤Ρưʤä
          .28.50 ֤ΥӥƱ褦˷֤ޤ
          ȤˤäơХ줿ӥ򸫤Ĥ뤳ȤǤ
          嵭ɤˡǳӥ򸫤ĤǤޤ
          ξϾȥåˡˤʤǤ礦

        . Narrow it down to a subdirectory

        ѹ򥵥֥ǥ쥯ȥñ̤˹ʤ

          - Copy kernel that works into "test".  Let's say that 3.62 works,
            but 3.63 doesn't.  So you diff -r those two kernels and come
            up with a list of directories that changed.  For each of those
            directories:

          - ư륫ͥ "test" ǥ쥯ȥ˥ԡޤ
          㤨 3.62 ưΤǡ3.63 ưʤΤȤ
          2 ĤΥͥ diff -r ơѹ줿ǥ쥯ȥ
          ꥹȤޤΥꥹγƥǥ쥯ȥФơ

                Copy the non-working directory next to the working directory
                as "dir.63".  
                One directory at time, try moving the working directory to
                "dir.62" and mv dir.63 dir"time, try 

                ưʤǥ쥯ȥưǥ쥯ȥ
                Ʊؤ "dir.63" ʤɤȤ̾ˤƥԡޤ
                ưǥ쥯ȥȡưʤǥ쥯ȥ
                ̾򼡤Τ褦ѤƤߤƤ

                        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.  

                줫ƥƥȤ뤿˥ӥɤƤ¸ط
                ˤѹʬƤΥ֥ǥ쥯ȥ˴ޤޤƤ
                Ȳꤹȡѹ줿ǥ쥯ȥˤ뤳
                ȤǤϤǤ

                Problems: changes in header files may have occurred; I've
                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.  

          - ǥ쥯ȥγƥեФơѹϤΥե
            ޤޤƤȲꤷޤ
            
        . Narrow it down to a routine

        ѹñ̤õ

          - You can take the old file and the new file and manually create
            a merged file that has

          - ΥӥΥե뤫롼򼡤Τ褦ˤƼư
            ޡޤ

                #ifdef VER62
                routine()
                {
                        ...
                }
                #else
                routine()
                {
                        ...
                }
                #endif

            And then walk through that file, one routine at a time and
            prefix it with

            줫ޡΥե1 ĤΥ롼󤴤Ȥ˼Τ褦 
            prefix ꤷư򸫤ƤäƤ

                #define VER62
                /* both routines here */
                #undef VER62

            Then recompile, retest, move the ifdefs until you find the one
            that makes the difference.

            ƺƥѥ롢ƥƥȤԤξԤư㤦
            ĤޤХȯƤʬ򸫤Ĥޤ ifdef ʬ
            ܤƤäƤߤƤĤޤꡢХȯ롼
            򸫤Ĥޤǡ٤ˣ롼ˤ #ifdef Ĥƥƥ
            ȤƤʤȤȤäƤޤˡ

Finally, you take all the info that you have, kernel revisions, bug
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.

Ǹ˽᤿  ͥΥӥ󡢥ХѹõԤ
Ĥǽĥʬ  򤽤ΡʥХνФ˥Υƥʡ
ȻפͤϤƤlinux.dev.kernel ˥ݥȤƤ褤Ǥ礦
ϰϤʤäƤФǤ

If you get it down to a routine, you'll probably get a fix in 24 hours.

⤷ϰϤ롼ˤޤǹʤäƤΤǤС餯 24 
ϽǤ礦

My apologies to Linus and the other kernel hackers for describing this
brute force approach, it's hardly what a kernel hacker would do.  However,
it does work and it lets non-hackers help fix bugs.  And it is cool
because Linux snapshots will let you do this - something that you can't
do with vendor supplied releases.

Linux ¾ΥͥϥåãˤϡιӤäݤˡǤˤĤ
ƼդʤФޤ󡣥ͥϥå٤ȤȤϸʤ
⤷ޤ󡣤ǤǤȯ뤳ȤϲǽǤϥå
ʳοͤˤХեåμ򤷤Ƥ館ޤΤ褦ʤȤ
ǤΤ餷ȤǤ Linux ΥʥåץåȤ
Ƥ뤪Ǥ͡٥ʪǤϤǤʤȤǤĤޤ
 Unix Ȥϰ㤤Ƥ뤫餳Τ褦ˡ
ХפǤƿ®ʥХեåȤץ󥽡
ΤȤǤ
---------------
ܸ  (1999/04/18)
    JF Project (2004/03/23)
