Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[IPX\]\:\s+Fix\s+checksum\s+computation\.\s*$/: 32 ]

Total 32 documents matching your query.

1. /net/bonding dir (score: 1)
Author: ik@xxxxxx>
Date: Fri, 31 Oct 2003 13:24:06 -0800
pply Amir's patch, as it seems to work just fine except for this ignorable problem? I'll append the patch below for your convenience. -J -- -Jay Vosburgh, IBM
/archives/netdev/2003-10/msg00719.html (9,225 bytes)

2. sum computation. (score: 1)
Author: mw2@xxxxxxxxxxxxx>
Date: Fri, 31 Oct 2003 13:23:31 -0800
or comment, it just appeared in the source. Why is this a "fix"? Performance? It seems more like someone's idea of code neatening. If this is done, why not if
/archives/netdev/2003-10/msg00720.html (9,631 bytes)

3. sum computation. (score: 1)
Author: ldma@xxxxxxxxx>
Date: Fri, 31 Oct 2003 19:31:59 -0200
he original code, we're as mystified as you are as to why it is that: if (sum & 0x10000) { sum++; sum &= 0xffff; } works while: sum = ((sym >> 16) + sum) & 0x
/archives/netdev/2003-10/msg00721.html (11,008 bytes)

4. sum computation. (score: 1)
Author: David S. Miller" <davem@xxxxxxxxxx>
Date: Fri, 31 Oct 2003 19:34:17 -0200
, Joe Perches escreveu: No, the reverse is true, with the patch it is the same as in 2.4, when Stephen did the conversion to handle paged skbs it did what you
/archives/netdev/2003-10/msg00722.html (9,278 bytes)

5. sum computation. (score: 1)
Author: <fubar@xxxxxxxxxx>
Date: Fri, 31 Oct 2003 13:50:04 -0800
hen did the conversion to handle paged skbs it did what you
/archives/netdev/2003-10/msg00723.html (10,411 bytes)

6. sum computation. (score: 1)
Author: <joe@xxxxxxxxxxx>
Date: Fri, 31 Oct 2003 19:56:52 -0200
over the place would need this "fix". Was an old NG Sniffer being used to verify this? Sniffer had a long term problem with IPX checksums. Has the gcc team b
/archives/netdev/2003-10/msg00724.html (11,787 bytes)

7. sum computation. (score: 1)
Author: xxxxx>
Date: Fri, 31 Oct 2003 13:53:28 -0800
Joe Perches escreveu: I guess so. If people with an Appletalk testbed could try with and without the patch, that would be great. Haven't noticed any other pl
/archives/netdev/2003-10/msg00725.html (10,443 bytes)

8. sum computation. (score: 1)
Author: @xxxxxxxxxxxxxxxx>
Date: Fri, 31 Oct 2003 14:21:31 -0800
running the old code and the new code, they produced different checksums on every sendmsg() call. He then tested it further by making sure he could use netata
/archives/netdev/2003-10/msg00726.html (10,704 bytes)

9. sum computation. (score: 1)
Author: elo <acme@xxxxxxxxxxxxxxxx>
Date: Fri, 31 Oct 2003 20:46:04 -0200
ent in I did testing between old 2.4.x and 2.6.x as well as standalone comparisons. The problem is a compiler screwup, that probably isn't worth investigating
/archives/netdev/2003-10/msg00727.html (11,483 bytes)

10. th IPv6 enabled) (score: 1)
Author: vem@xxxxxxxxxx>
Date: Fri, 31 Oct 2003 16:29:45 -0700
i, Oct 31, 2003 at 02:55:42PM -0800, Andrew Morton escreveu: Ouch, it seems this one is a die hard, Rafaelle, could you please test it without IPv6? - Arnaldo
/archives/netdev/2003-10/msg00730.html (12,556 bytes)

11. sum computation. (score: 1)
Author: nger <shemminger@xxxxxxxx>
Date: Fri, 31 Oct 2003 16:31:29 -0800
3 13:24:06 -0800 Joe Perches <joe@xxxxxxxxxxx> wrote: Why is this a "fix"? Performance? It seems more like someone's idea of code neatening. IPC checksums wer
/archives/netdev/2003-10/msg00731.html (9,675 bytes)

12. sum computation. (score: 1)
Author: aldo Carvalho de Melo <acme@xxxxxxxxxxxxxxxx>
Date: Fri, 31 Oct 2003 16:25:16 -0800
omeone's idea of code neatening. IPC checksums wer
/archives/netdev/2003-10/msg00732.html (10,033 bytes)

13. sum computation. (score: 1)
Author: xxxxxxx>
Date: Fri, 31 Oct 2003 16:31:24 -0800
d on expectation rather than code.
/archives/netdev/2003-10/msg00733.html (9,638 bytes)

14. sum computation. (score: 1)
Author: >
Date: Fri, 31 Oct 2003 16:38:43 -0800
k his analysis is correct and that the two pieces of C code are really doing different things.
/archives/netdev/2003-10/msg00734.html (10,950 bytes)

15. sum computation. (score: 1)
Author: xxxxxxxxx>
Date: Fri, 31 Oct 2003 23:13:01 -0200
talk) Here is the old loop: while (len--) { sum += *data; sum <<=1; if (sum & 0x10000) { sum++; sum &= 0xffff; } data++; } My buggy loop is: while (len--) { s
/archives/netdev/2003-10/msg00735.html (11,687 bytes)

16. sum computation. (score: 1)
Author: es <joe@xxxxxxxxxxx>
Date: Fri, 31 Oct 2003 23:19:26 -0200
0000) { sum++; sum &= 0xffff; } data++; } My buggy loop is: while (len--) { s
/archives/netdev/2003-10/msg00736.html (12,524 bytes)

17. Re: [IPX]: Fix checksum computation. (score: 1)
Author: Joe Perches <joe@xxxxxxxxxxx>
Date: Fri, 31 Oct 2003 13:24:06 -0800
This change didn't appear on this list for comment, it just appeared in the source. Why is this a "fix"? Performance? It seems more like someone's idea of code neatening. If this is done, why not if
/archives/netdev/2003-10/msg01461.html (9,351 bytes)

18. Re: [IPX]: Fix checksum computation. (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Fri, 31 Oct 2003 13:23:31 -0800
IPC checksums were being miscomputed in the original code, we're as mystified as you are as to why it is that: if (sum & 0x10000) { sum++; sum &= 0xffff; } works while: sum = ((sym >> 16) + sum) & 0x
/archives/netdev/2003-10/msg01462.html (9,760 bytes)

19. Re: [IPX]: Fix checksum computation. (score: 1)
Author: Arnaldo Carvalho de Melo <acme@xxxxxxxxxxxxxxxx>
Date: Fri, 31 Oct 2003 19:31:59 -0200
Em Fri, Oct 31, 2003 at 01:24:06PM -0800, Joe Perches escreveu: No, the reverse is true, with the patch it is the same as in 2.4, when Stephen did the conversion to handle paged skbs it did what you
/archives/netdev/2003-10/msg01463.html (11,137 bytes)

20. Re: [IPX]: Fix checksum computation. (score: 1)
Author: Arnaldo Carvalho de Melo <acme@xxxxxxxxxxxxxxxx>
Date: Fri, 31 Oct 2003 19:34:17 -0200
Em Fri, Oct 31, 2003 at 01:23:31PM -0800, David S. Miller escreveu: s/IPX/Appletalk/g 8) - Arnaldo
/archives/netdev/2003-10/msg01464.html (9,448 bytes)


This search system is powered by Namazu