[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.095 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site