Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*pppoe\s+and\s+receive\s+checksum\s+offload\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*pppoe\s+and\s+receive\s+checksum\s+offload\s*$/: 22 ]

Total 22 documents matching your query.

1. Re: pppoe and receive checksum offload (score: 1): Author: " <davem@xxxxxxxxxxxxx>; Date: Wed, 9 Mar 2005 21:13:15 -0800; I'm not so picky about the names. Patch applied, thanks Herbert :-) If Stephen cares, he can try to submit his patch for 2.6.11.x via stable@xxxxxxxxxx, I have no problem with that.; /archives/netdev/2005-03/msg00636.html (8,225 bytes)
2. pppoe and receive checksum offload (score: 1): Author: istian Schmid <webmaster@xxxxxxxxxxxxxx>; Date: Thu, 24 Feb 2005 15:59:06 -0800; Someone reported a problem with skge hardware receive checksumming and PPPOE but it looks like a generic problem. Since PPPOE adds additional header bytes the hardware computed checksum will be wrong; /archives/netdev/2005-02/msg00902.html (8,744 bytes)
3. Re: pppoe and receive checksum offload (score: 1): Author: rancois Romieu <romieu@xxxxxxxxxxxxx>; Date: Sun, 27 Feb 2005 20:20:11 -0800; Changing or expanding the link level headers should only mess up the hw checksum if you are using CHECKSUM_HW, is that what your skge driver is using?; /archives/netdev/2005-02/msg00964.html (8,813 bytes)
4. Re: pppoe and receive checksum offload (score: 1): Author:; Date: Mon, 28 Feb 2005 12:21:30 +0300; Well, even if this driver uses CHECKSUM_UNNECESSARY, the bug is still apparently present for another devices which use CHECKSUM_HW. Actually, the bug is in ppp_input(). It is responsible for setting; /archives/netdev/2005-02/msg00975.html (9,582 bytes)
5. Re: pppoe and receive checksum offload (score: 1): Author: n@xxxxxxxx>; Date: Mon, 28 Feb 2005 22:31:06 +1100; This penalises CHECKSUM_HW. We should have a generic helper function that does the checksum folding for CHECKSUM_HW and if otherwise set ip_summed to CHECKSUM_NONE. In fact it looks like the current; /archives/netdev/2005-02/msg00976.html (9,767 bytes)
6. Re: pppoe and receive checksum offload (score: 1): Author:; Date: Mon, 28 Feb 2005 22:39:38 +1100; Actually ip_gre is probably right. It seems that CHECKSUM_UNNECESSARY should not be set for PPPOE/GRE packets at all. So it would be a bug in the sk* driver. Alexey/Dave, is this interpretation of ip; /archives/netdev/2005-02/msg00977.html (9,415 bytes)
7. Re: pppoe and receive checksum offload (score: 1): Author: rt@xxxxxxxxxxxxxxxxxxx>; Date: Mon, 28 Feb 2005 17:04:01 +0300; What's about CHECKSUM_UNNECESSARY, yes, it is set only for TCP/UDP packets, when device verifies the checksum itself. It is not the case for PPOE frames. CHECKSUM_HW is more flxible, ipip/gre tunnel; /archives/netdev/2005-02/msg00984.html (9,843 bytes)
8. Re: pppoe and receive checksum offload (score: 1): Author: uznetsov <kuznet@xxxxxxxxxxxxx>; Date: Mon, 28 Feb 2005 09:12:52 -0800; Someone reported a problem with skge hardware receive checksumming and PPPOE but it looks like a generic problem. Since PPPOE adds additional header bytes the hardware computed checksum will be wrong; /archives/netdev/2005-02/msg00991.html (9,674 bytes)
9. Re: pppoe and receive checksum offload (score: 1): Author: <asimshankar@xxxxxxxxx>; Date: Mon, 28 Feb 2005 15:32:28 -0800; Because there is a bug in the chip wherein checksums can be miscalculated. I forget the details, but I do remember that you can't enable checksumming safely because of this. In drivers/net/sk98lin/sk; /archives/netdev/2005-02/msg01009.html (9,068 bytes)
10. Re: pppoe and receive checksum offload (score: 1): Author: arzik@xxxxxxxxx>; Date: Mon, 28 Feb 2005 16:01:33 -0800 (PST); The driver covers two types of chips (Genesis and Yukon). The new driver only allows receive checksum on Yukon chipset. Almost all current hardware uses Yukon and it has been pretty well tested. The; /archives/netdev/2005-02/msg01010.html (10,087 bytes)
11. Re: pppoe and receive checksum offload (score: 1): Author: ieu@xxxxxxxxxxxxx>; Date: Tue, 1 Mar 2005 12:04:24 +1100; Agreed. We should use Stephen's patch for 2.6.11. For 2.6.12, does this patch look sane? As usual, I'd love to get some better names for the new helper functions. Cheers, -- Visit Openswan at http://; /archives/netdev/2005-02/msg01015.html (10,065 bytes)
12. Re: pppoe and receive checksum offload (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Wed, 9 Mar 2005 21:13:15 -0800; I'm not so picky about the names. Patch applied, thanks Herbert :-) If Stephen cares, he can try to submit his patch for 2.6.11.x via stable@xxxxxxxxxx, I have no problem with that.; /archives/netdev/2005-03/msg02559.html (8,572 bytes)
13. pppoe and receive checksum offload (score: 1): Author: Stephen Hemminger <shemminger@xxxxxxxx>; Date: Thu, 24 Feb 2005 15:59:06 -0800; Someone reported a problem with skge hardware receive checksumming and PPPOE but it looks like a generic problem. Since PPPOE adds additional header bytes the hardware computed checksum will be wrong; /archives/netdev/2005-02/msg01922.html (8,744 bytes)
14. Re: pppoe and receive checksum offload (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Sun, 27 Feb 2005 20:20:11 -0800; Changing or expanding the link level headers should only mess up the hw checksum if you are using CHECKSUM_HW, is that what your skge driver is using?; /archives/netdev/2005-02/msg01984.html (8,875 bytes)
15. Re: pppoe and receive checksum offload (score: 1): Author: Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>; Date: Mon, 28 Feb 2005 12:21:30 +0300; Hello! Well, even if this driver uses CHECKSUM_UNNECESSARY, the bug is still apparently present for another devices which use CHECKSUM_HW. Actually, the bug is in ppp_input(). It is responsible for s; /archives/netdev/2005-02/msg01995.html (9,687 bytes)
16. Re: pppoe and receive checksum offload (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Mon, 28 Feb 2005 22:31:06 +1100; This penalises CHECKSUM_HW. We should have a generic helper function that does the checksum folding for CHECKSUM_HW and if otherwise set ip_summed to CHECKSUM_NONE. In fact it looks like the current; /archives/netdev/2005-02/msg01996.html (9,874 bytes)
17. Re: pppoe and receive checksum offload (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Mon, 28 Feb 2005 22:39:38 +1100; Actually ip_gre is probably right. It seems that CHECKSUM_UNNECESSARY should not be set for PPPOE/GRE packets at all. So it would be a bug in the sk* driver. Alexey/Dave, is this interpretation of ip; /archives/netdev/2005-02/msg01997.html (9,549 bytes)
18. Re: pppoe and receive checksum offload (score: 1): Author: Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>; Date: Mon, 28 Feb 2005 17:04:01 +0300; Hello! What's about CHECKSUM_UNNECESSARY, yes, it is set only for TCP/UDP packets, when device verifies the checksum itself. It is not the case for PPOE frames. CHECKSUM_HW is more flxible, ipip/gre; /archives/netdev/2005-02/msg02004.html (9,961 bytes)
19. Re: pppoe and receive checksum offload (score: 1): Author: Stephen Hemminger <shemminger@xxxxxxxx>; Date: Mon, 28 Feb 2005 09:12:52 -0800; Someone reported a problem with skge hardware receive checksumming and PPPOE but it looks like a generic problem. Since PPPOE adds additional header bytes the hardware computed checksum will be wrong; /archives/netdev/2005-02/msg02011.html (9,779 bytes)
20. Re: pppoe and receive checksum offload (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Mon, 28 Feb 2005 15:32:28 -0800; Because there is a bug in the chip wherein checksums can be miscalculated. I forget the details, but I do remember that you can't enable checksumming safely because of this. In drivers/net/sk98lin/sk; /archives/netdev/2005-02/msg02029.html (9,184 bytes)

Current List: 1 - 20
Page: [1] [2]