From mboxrd@z Thu Jan 1 00:00:00 1970 From: Harry Kalogirou Subject: Re: [SOLVED] Re: webserver stalls [was Re: bug in (linux) slattach] Date: 23 Oct 2002 14:42:25 +0300 Sender: linux-8086-owner@vger.kernel.org Message-ID: <1035372121.2230.30.camel@cool> References: Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Id: Content-Type: text/plain; charset="us-ascii" To: jb1@btstream.com Cc: Linux-8086 > Maybe not. I found ip.c Version 1.9 by browsing the CVS repository and, as > far as I can tell, the only change was that you moved the first "dec cx"; > this will have *no* effect. The algorithm can still fail if the carry flag > happens to be set going into the routine, or if there is a carry generated > the last time "adc [di]" is executed. I suggest something like this for > _ip_calc_chksum: > > push bp > mov bp,sp > push di > > mov cx, 6[bp] > sar cx, 1 > dec cx > xor ax,ax ; clear carry flag (as well as AX) > mov di, 4[bp] > mov ax, [di] > inc di > inc di > loop1: > adc ax, [di] > inc di > inc di > > loop loop1; ; a byte shorter and a clock faster > ; than DEC CX/JNZ LOOP1 > > adc ax,0 ; add (just) the final carry > not ax > > pop di > pop bp > > ret > You can't be more right 8). I just thought I could get away without opening the 8086 instruction manual, and I just made bad assumptions about when the carry flag is cleared. The CVS now contains all your bugfixes (clear carry before entering the loop, adding last carry), the use of "loop" and I also unrolled the loop once. A code review would be gladly appreciated. > Of course, this algorithm is valid only if the length (6[bp]) is an even > number of bytes. While this is always true for IP headers, for TCP packet > checksums there would have to be a final test of the length's low bit and > appropriate handling of an additional odd byte. TCP uses another routine. Harry