Messages in this thread |  | | Date | Fri, 23 Aug 1996 07:52:11 +0300 (EET DST) | From | Linus Torvalds <> | Subject | Re: 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).
Linus
|  |