Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unittests stuck in test_ocxl_afu_attach() #29

Open
sharkcz opened this issue Apr 30, 2019 · 5 comments
Open

unittests stuck in test_ocxl_afu_attach() #29

sharkcz opened this issue Apr 30, 2019 · 5 comments

Comments

@sharkcz
Copy link

sharkcz commented Apr 30, 2019

I have a problem with the unittests, it gets stuck in test_ocxl_afu_attach() (almost) every time. See the output below. The environment is libocxl from github master, Fedora 28 with kernel-5.1.0-0.rc5.git0.1.fc31.op.1.ppc64le, HW is Power9 Talos II bare metal.

[dan@talos libocxl]$ make test V=1                                                                                                                                                     :master
sudo testobj/unittests
Starting test AFU:init
OK
Starting test AFU:ocxl_afu_alloc
OK
Starting test AFU:device_matches
OK
Starting test AFU:populate_metadata
OK
Starting test AFU:getters
   unique: 140735475091664, success, outsize: 24
OK
Starting test AFU:get_afu_by_path
OK
Starting test AFU:afu_open
   unique: 140735475091664, success, outsize: 24
OK
Starting test AFU:ocxl_afu_open_specific
OK
Starting test AFU:ocxl_afu_open_from_dev
OK
Starting test AFU:ocxl_afu_open
OK
Starting test AFU:ocxl_afu_attach
   unique: 140735475089536, success, outsize: 24

^C^C
make: *** [Makefile:84: test] Zabit (SIGKILL)

output of ps shows

...
11377 pts/1    S+     0:00 sudo testobj/unittests
11379 pts/1    Dl+    0:00 testobj/unittests
...

and trying to attach either strace or gdb leads nowhere, they get stuck as well.

@deece
Copy link
Contributor

deece commented Apr 30, 2019

The use of fuse makes these tests flakey as
best, there is also a race condition in fuse that i have not been able to work around that I suspect you are hitting.

I would suggest testing with real hardware (like the memcpy AFU) instead

@sharkcz
Copy link
Author

sharkcz commented Apr 30, 2019

Thanks for info, I too suspected fuse ... I'll see what I can do, my goal is to have some basic testing for distro builds, so relying on real hw might be difficult.

@deece deece closed this as completed Jul 2, 2019
@ajdlinux
Copy link
Member

ajdlinux commented Jul 2, 2019

@deece we need to document that

@deece
Copy link
Contributor

deece commented Jul 2, 2019

I think a better choice would be to disable any subtests that are subject to the races

@deece deece reopened this Jul 2, 2019
@deece
Copy link
Contributor

deece commented Jul 2, 2019

Hmm, it's not that simple, the tests work the first time through, then hang in the open call on subsequent runs.

rmmod cuse before the run fixes the problem, but adding it to the script may mess up other users of cuse.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants