On 2/16/23 4:00?PM, John David Anglin wrote: > Running test buf-ring.t bad run 0/0 = -233 > test_running(1) failed > Test buf-ring.t failed with ret 1 As mentioned previously, this one and the other -233 I suspect are due to the same coloring issue as was fixed by Helge's patch for the ring mmaps, as the provided buffer rings work kinda the same way. The application allocates some aligned memory, and registers it and the kernel then maps it. I wonder if these would work properly if the address was aligned to 0x400000? Should be easy to verify, just modify the alignment for the posix_memalign() calls in test/buf-ring.c. > Running test file-verify.t Found 98528, wanted 622816 > Buffered novec reg test failed > Test file-verify.t failed with ret 1 Unsure what this is. > Tests timed out (2): <a4c0b3decb33.t> <send-zerocopy.t> I suspect the box is just too slow to run these before the script decides they have timed out. > I modified poll-race-mshot.t to skip on hppa. Added handle_tw_list > and io_uring_try_cancel_requests fixes. This appears to have fixed > stalls. poll-race-mshot is the most interesting one, but I'll need som actual info on that one to make guesses as to what is going on. A raw hex trace doesn't really help me very much... But I don't think we'll make much progress here unless someone dives in and takes a closer look. So while I appreciate the test report, we need to dig a bit deeper to figure out poll-race-mshot and file-verify. qemu may be useful for some things, but it's not of much help here. -- Jens Axboe
