[lkml]   [1996]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: TCP/buffering changes

    [ To linux-kernel: this is a generic request when doing bug-reports that
    developers can't reproduce easily. The testing can take some time, but
    this way as much of the work in bug-tracking as possible is "distributed"
    and we can do it more efficiently ]

    On Thu, 22 Aug 1996, Darren Crane wrote:
    > 2.0.14 vs. pre2.0.7
    > ------- --------
    > 10 secs 1.5 secs hmmmmm.....

    Would you be willing to do a few tests for me, please?

    The first test is simply to determine exactly _which_ kernel breaks. The
    fastest way to do that is to do a "binary search": start off with 2.0.10, for
    example, and if that doesn't show the problems go to 2.0.12, and then to
    2.0.11 if .12 is broken..

    If you're using patches, this isn't actually too hard: you can "reverse"
    a patch by using the "-R" flag, so you can go backwards too. For example,
    if you have 2.0.12 and want to go backwards to 2.0.10, you can do

    cd /usr/src/linux
    zcat < xxx/patch-2.0.12.gz | patch -p1 -R
    zcat < xxx/patch-2.0.11.gz | patch -p1 -R

    /* and if everything went ok: */
    rm `find . -name '*.orig'`

    The more you can narrow down exactly which patch breaks, the better: it helps
    developers a LOT to get even just the exact patch that broke something, and
    if you are adventurous and know how "patch" works, you can even try to
    pinpoint exactly which _part_ of the patch broke for you (but you don't have
    to do that - it's strictly for people who _really_ know the kernel).


     \ /
      Last update: 2005-03-22 13:38    [W:0.020 / U:21.492 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site