Re: cassini driver and IPv6

Re: cassini driver and IPv6

[David Monro]

Well, I thought I would take another look at this, since I saw lots of 
cassini-related code going into the kernel and its been some time since 
I last played with this...

I'm using a board with Natsemi Saturn chips (one of the gigaswifts with 
2xGig ether and 2x scsi), on a little-endian PC rather than a sparc box 
(not that that should matter...). _Most_ IPV6 packets don't seem to get 
checksummed correctly  (they trigger the eth1: hw csum failure message 
and a traceback as follows:

   [<c010505a>] show_trace_log_lvl+0x1a/0x30
   [<c0105a72>] show_trace+0x12/0x20
   [<c010642a>] dump_stack+0x6a/0x70
   [<c0292f01>] netdev_rx_csum_fault+0x31/0x40
   [<c028f300>] __skb_checksum_complete_head+0x60/0x70
   [<c028f31b>] __skb_checksum_complete+0xb/0x10
   [<e0fba769>] tcp_v6_rcv+0x459/0x920 [ipv6]
   [<e0f9aa4f>] ip6_input_finish+0x12f/0x340 [ipv6]
   [<e0f9ac7f>] ip6_input+0x1f/0x60 [ipv6]
   [<e0f9af55>] ipv6_rcv+0x1f5/0x340 [ipv6]
   [<c0292b54>] netif_receive_skb+0x364/0x510
   [<c02958f6>] process_backlog+0x66/0xd0
   [<c02953ee>] net_rx_action+0x15e/0x210
   [<c0123f52>] __do_softirq+0x52/0xb0
   [<c0123ff6>] do_softirq+0x46/0x50
   [<c012445c>] irq_exit+0x6c/0x80
   [<c01065b3>] do_IRQ+0x53/0x90
   [<c0104afa>] common_interrupt+0x2e/0x34
   [<c0116971>] do_page_fault+0xa1/0x5f0
   [<c03081e2>] error_code+0x6a/0x70

).

(Not all packets trigger it; eg I sent a ping6 with a length of 2000, 
and as far as I can tell only the 2nd packet in each ping triggers the 
failure - odd. Does it depend on the v6 extension headers present or 
something I wonder. Actually, how on earth does the hardware produce the 
pseudo header for tcp? And even odder - how could it possibly go wrong 
with non-tcp packets like ping?)

Has anyone else ever tested a saturn (or actually any cassini device) 
using ipv6?

I've spent a while looking at the packet parser stuff but I have only a 
vague idea what it is doing and am certainly not in a position to debug 
it. My current solution is simply to only do the checksumming stuff at 
the bottom of cas_rx_process_pkt if ntohs(skb->protocol) == 0x0800 (ie, 
IPv4), else set skb->csum to CHECKSUM_NONE, which is kinda dirty. If 
someone with a non-saturn cassini can confirm that they don't get hw 
csum errors with ipv6, then I'd have to assume a saturn-only hardware 
bug and could wrap it with (cp->cas_flags & CAS_FLAG_SATURN) as well.

Does this seem reasonable?

Cheers,

	David



David S. Miller wrote:
> From: David Monro <davidm@davidmonro.net>
> Date: Mon, 14 Nov 2005 13:02:42 +1030
> 
>> I don't know if it just needs to be told not to calulate the checksums
>> for v6 packets, or what.
> 
> It generates a generic checksum calculation on all packets,
> similarly to the Sun GEM chip, which ought to be totally
> protocol agnostic.
> 
> The Cassini is a very complex chip, so debugging this without docs
> will be a chore.  There are many things that influence how this chip
> looks at the packet, including a packet parsing engine which tells it
> where to split packets up into header and data portions for zero-copy
> stuff.
> 
> Special versions of this packet parser are needed to workaround bugs
> in certain revisions of the chip, and I bet there are buffer alignment
> constraints on receive and other odd things that need to be right.
> 
> The only thing I can do to work on this bug is to use the driver
> source, and reproduce the bug here and just tinker around, which
> you can also do. :-)
> 
> 

Re: cassini driver and IPv6

[David Monro]

Oh duh. Forgot to say this is on 2.6.24.3 (not that the basic issue has 
changed in over 2 years...)

Cheers,

	David

David Monro wrote:
> Well, I thought I would take another look at this, since I saw lots of 
> cassini-related code going into the kernel and its been some time since 
> I last played with this...
> 
> I'm using a board with Natsemi Saturn chips (one of the gigaswifts with 
> 2xGig ether and 2x scsi), on a little-endian PC rather than a sparc box 
> (not that that should matter...). _Most_ IPV6 packets don't seem to get 
> checksummed correctly  (they trigger the eth1: hw csum failure message 
> and a traceback as follows:
> 
>   [<c010505a>] show_trace_log_lvl+0x1a/0x30
>   [<c0105a72>] show_trace+0x12/0x20
>   [<c010642a>] dump_stack+0x6a/0x70
>   [<c0292f01>] netdev_rx_csum_fault+0x31/0x40
>   [<c028f300>] __skb_checksum_complete_head+0x60/0x70
>   [<c028f31b>] __skb_checksum_complete+0xb/0x10
>   [<e0fba769>] tcp_v6_rcv+0x459/0x920 [ipv6]
>   [<e0f9aa4f>] ip6_input_finish+0x12f/0x340 [ipv6]
>   [<e0f9ac7f>] ip6_input+0x1f/0x60 [ipv6]
>   [<e0f9af55>] ipv6_rcv+0x1f5/0x340 [ipv6]
>   [<c0292b54>] netif_receive_skb+0x364/0x510
>   [<c02958f6>] process_backlog+0x66/0xd0
>   [<c02953ee>] net_rx_action+0x15e/0x210
>   [<c0123f52>] __do_softirq+0x52/0xb0
>   [<c0123ff6>] do_softirq+0x46/0x50
>   [<c012445c>] irq_exit+0x6c/0x80
>   [<c01065b3>] do_IRQ+0x53/0x90
>   [<c0104afa>] common_interrupt+0x2e/0x34
>   [<c0116971>] do_page_fault+0xa1/0x5f0
>   [<c03081e2>] error_code+0x6a/0x70
> 
> ).
> 
> (Not all packets trigger it; eg I sent a ping6 with a length of 2000, 
> and as far as I can tell only the 2nd packet in each ping triggers the 
> failure - odd. Does it depend on the v6 extension headers present or 
> something I wonder. Actually, how on earth does the hardware produce the 
> pseudo header for tcp? And even odder - how could it possibly go wrong 
> with non-tcp packets like ping?)
> 
> Has anyone else ever tested a saturn (or actually any cassini device) 
> using ipv6?
> 
> I've spent a while looking at the packet parser stuff but I have only a 
> vague idea what it is doing and am certainly not in a position to debug 
> it. My current solution is simply to only do the checksumming stuff at 
> the bottom of cas_rx_process_pkt if ntohs(skb->protocol) == 0x0800 (ie, 
> IPv4), else set skb->csum to CHECKSUM_NONE, which is kinda dirty. If 
> someone with a non-saturn cassini can confirm that they don't get hw 
> csum errors with ipv6, then I'd have to assume a saturn-only hardware 
> bug and could wrap it with (cp->cas_flags & CAS_FLAG_SATURN) as well.
> 
> Does this seem reasonable?
> 
> Cheers,
> 
>     David
> 
> 
> 
> David S. Miller wrote:
>> From: David Monro <davidm@davidmonro.net>
>> Date: Mon, 14 Nov 2005 13:02:42 +1030
>>
>>> I don't know if it just needs to be told not to calulate the checksums
>>> for v6 packets, or what.
>>
>> It generates a generic checksum calculation on all packets,
>> similarly to the Sun GEM chip, which ought to be totally
>> protocol agnostic.
>>
>> The Cassini is a very complex chip, so debugging this without docs
>> will be a chore.  There are many things that influence how this chip
>> looks at the packet, including a packet parsing engine which tells it
>> where to split packets up into header and data portions for zero-copy
>> stuff.
>>
>> Special versions of this packet parser are needed to workaround bugs
>> in certain revisions of the chip, and I bet there are buffer alignment
>> constraints on receive and other odd things that need to be right.
>>
>> The only thing I can do to work on this bug is to use the driver
>> source, and reproduce the bug here and just tinker around, which
>> you can also do. :-)
>>
>>
> 
> 

Re: cassini driver and IPv6

[David Miller]

From: David Monro <davidm@davidmonro.net>
Date: Mon, 10 Mar 2008 15:51:22 +1030

> I've spent a while looking at the packet parser stuff but I have only a 
> vague idea what it is doing and am certainly not in a position to debug 
> it. My current solution is simply to only do the checksumming stuff at 
> the bottom of cas_rx_process_pkt if ntohs(skb->protocol) == 0x0800 (ie, 
> IPv4), else set skb->csum to CHECKSUM_NONE, which is kinda dirty. If 
> someone with a non-saturn cassini can confirm that they don't get hw 
> csum errors with ipv6, then I'd have to assume a saturn-only hardware 
> bug and could wrap it with (cp->cas_flags & CAS_FLAG_SATURN) as well.
> 
> Does this seem reasonable?

Sorry for letting this sit for so long.

It's better to get this working using your suggested workaround
for the time being, so I'll push the following fix upstream.

BTW, the cassini chips (as well as several other pices of
sun hardware) are fully documented at:

	http://wikis.sun.com/display/FOSSdocs

Thanks.

cassini: Only use chip checksum for ipv4 packets.

According to David Monro, at least with Natsemi Saturn chips the
cassini driver has some trouble with ipv6 checksums.

Until we have more information about what's going on here, only
use the chip checksums for ipv4.

This workaround was suggested and tested by David.

Update version and release date.

Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/cassini.c |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/net/cassini.c b/drivers/net/cassini.c
index 93e1363..83768df 100644
--- a/drivers/net/cassini.c
+++ b/drivers/net/cassini.c
@@ -142,8 +142,8 @@
 
 #define DRV_MODULE_NAME		"cassini"
 #define PFX DRV_MODULE_NAME	": "
-#define DRV_MODULE_VERSION	"1.5"
-#define DRV_MODULE_RELDATE	"4 Jan 2008"
+#define DRV_MODULE_VERSION	"1.6"
+#define DRV_MODULE_RELDATE	"21 May 2008"
 
 #define CAS_DEF_MSG_ENABLE	  \
 	(NETIF_MSG_DRV		| \
@@ -2136,9 +2136,12 @@ end_copy_pkt:
 		if (addr)
 			cas_page_unmap(addr);
 	}
-	skb->csum = csum_unfold(~csum);
-	skb->ip_summed = CHECKSUM_COMPLETE;
 	skb->protocol = eth_type_trans(skb, cp->dev);
+	if (skb->protocol == htons(ETH_P_IP)) {
+		skb->csum = csum_unfold(~csum);
+		skb->ip_summed = CHECKSUM_COMPLETE;
+	} else
+		skb->ip_summed = CHECKSUM_NONE;
 	return len;
 }
 
-- 
1.5.5.1.308.g1fbb5