Messages in this thread | | | Date | Mon, 12 Feb 2024 17:53:01 -0800 | Subject | Re: [PATCH v7 2/2] lib: checksum: Use aligned accesses for ip_fast_csum and csum_ipv6_magic tests | From | Guenter Roeck <> |
| |
On 2/12/24 16:32, Charlie Jenkins wrote: > On Mon, Feb 12, 2024 at 04:14:49PM -0800, Guenter Roeck wrote: >> On 2/12/24 12:33, Charlie Jenkins wrote: >>> The test cases for ip_fast_csum and csum_ipv6_magic were failing on a >>> variety of architectures that are big endian or do not support >>> misalgined accesses. Both of these test cases are changed to support big >>> and little endian architectures. >>> >>> The test for ip_fast_csum is changed to align the data along (14 + >>> NET_IP_ALIGN) bytes which is the alignment of an IP header. The test for >>> csum_ipv6_magic aligns the data using a struct. An extra padding field >>> is added to the struct to ensure that the size of the struct is the same >>> on all architectures (44 bytes). >>> >>> Fixes: 6f4c45cbcb00 ("kunit: Add tests for csum_ipv6_magic and ip_fast_csum") >>> Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> >> >> This thing really wants to annoy me. Now I get: >> >> # test_csum_ipv6_magic: ASSERTION FAILED at lib/checksum_kunit.c:494 >> Expected ( u64)csum_result == ( u64)expected, but >> ( u64)csum_result == 46543 (0xb5cf) >> ( u64)expected == 46544 (0xb5d0) >> not ok 5 test_csum_ipv6_magic >> >> with the parisc64 tests. All other architectures / platforms work fine >> after applying the various pending fixes. It looks like a carry gets >> lost somewhere, but I have not been able to figure out where exactly >> that happens. This only happens with the 64-bit hppa assembler code. >> >> Guenter >> > > How do you test parisc64? It's not in buildroot which I have been using > to test the other architectures. >
Its qemu support is quite new. 32 bit userspace should work.
The errors are quite interesting.
[ 16.989782] ###### i=1 len=0xd22c123d proto=0xb1 csum=0x88e31421 expected=0xb5d0 -> csum 0xb5cf [ 16.990249] ###### i=3 len=0xb15e4531 proto=0xba csum=0xa2853676 expected=0xe6c1 -> csum 0xe6c0 [ 16.992119] ###### i=5 len=0xbad8adbb proto=0xce csum=0x9e498ff7 expected=0xa836 -> csum 0xa835 [ 16.992498] ###### i=7 len=0xceeaefca proto=0x5c csum=0x2c29f715 expected=0xe87c -> csum 0xe87b [ 16.992769] ###### i=9 len=0x5c1d4d09 proto=0x8c csum=0x1fe21431 expected=0x5875 -> csum 0x5874 [ 16.993026] ###### i=11 len=0x8c075723 proto=0x93 csum=0x1f6f03e1 expected=0xd361 -> csum 0xd360 [ 16.993282] ###### i=13 len=0x93195303 proto=0x8e csum=0x45499a3b expected=0xdd50 -> csum 0xdd4f [ 16.993538] ###### i=15 len=0x8e0c125d proto=0x9a csum=0x8ab89b8c expected=0xad6b -> csum 0xad6a [ 16.993790] ###### i=17 len=0x9a03e5a2 proto=0x7e csum=0x43d23b4e expected=0x90b5 -> csum 0x90b4
Every odd index fails, and the returned value is one less than the expected value. It is almost as if something goes wrong with 64-bit loads from 32-bit aligned addresses. I'll do some more debugging.
Guenter
| |