USB hang on Ubnutu 19.04 with pkcs11 branch

[dspearl-amazon]

When trying to access a USB HID device, output hangs after C_Initialize:144 debug output

Here's GDB stack traces of each thread. The same build appears to work on an Ubuntu 18.04 laptop

(gdb) bt
#0  futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x5555555cbc10)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x5555555cbbc0, cond=0x5555555cbbe8) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x5555555cbbe8, mutex=0x5555555cbbc0) at pthread_cond_wait.c:655
#3  0x00007ffff75d5c6b in hid_read_timeout (dev=0x5555555cbb90, data=data@entry=0x7fffffffe120 "", length=length@entry=41, milliseconds=-1)
    at /home/user/pkcs11/cryptoauthlib/third_party/hidapi/libusb/hid.c:1107
#4  0x00007ffff75d5dc1 in hid_read (dev=<optimized out>, data=data@entry=0x7fffffffe120 "", length=length@entry=41)
    at /home/user/pkcs11/cryptoauthlib/third_party/hidapi/libusb/hid.c:1163
#5  0x00007ffff75d6a44 in kit_phy_receive (iface=iface@entry=0x5555555cb300, rxdata=rxdata@entry=0x7fffffffe120 "", 
    rxsize=rxsize@entry=0x7fffffffe0b4) at /home/user/pkcs11/cryptoauthlib/lib/hal/hal_all_platforms_kit_hidapi.c:267
#6  0x00007ffff75d4a75 in kit_init (iface=iface@entry=0x5555555cb300) at /home/user/pkcs11/cryptoauthlib/lib/hal/kit_protocol.c:137
#7  0x00007ffff75d680c in hal_kit_hid_post_init (iface=0x5555555cb300)
    at /home/user/pkcs11/cryptoauthlib/lib/hal/hal_all_platforms_kit_hidapi.c:166
#8  0x00007ffff75c58d1 in atinit (ca_iface=0x5555555cb300) at /home/user/pkcs11/cryptoauthlib/lib/atca_iface.c:119
#9  0x00007ffff75c53a1 in newATCADevice (cfg=cfg@entry=0x7ffff75f0f40 <cfg_ateccx08a_kithid_default>)
    at /home/user/pkcs11/cryptoauthlib/lib/atca_device.c:74
#10 0x00007ffff75ca633 in atcab_init (cfg=cfg@entry=0x7ffff75f0f40 <cfg_ateccx08a_kithid_default>)
    at /home/user/pkcs11/cryptoauthlib/lib/basic/atca_basic.c:85
#11 0x00007ffff75df4b8 in pkcs11_slot_init (slotID=slotID@entry=0) at /home/user/pkcs11/cryptoauthlib/lib/pkcs11/pkcs11_slot.c:196
#12 0x00007ffff75d90cf in pkcs11_init (pInitArgs=pInitArgs@entry=0x5555555c8450)
    at /home/user/pkcs11/cryptoauthlib/lib/pkcs11/pkcs11_init.c:249
#13 0x00007ffff75d9fb3 in C_Initialize (pInitArgs=0x5555555c8450) at /home/user/pkcs11/cryptoauthlib/lib/pkcs11/pkcs11_main.c:145
#14 0x00007ffff7900825 in initialize_module_inlock_reentrant (mod=0x5555555c8230, init_args=0x5555555c8450, init_args@entry=0x0)
    at p11-kit/modules.c:738
#15 0x00007ffff79009df in managed_C_Initialize (self=0x5555555ca100, init_args=0x0) at p11-kit/modules.c:1584
#16 0x00007ffff7903bd3 in p11_kit_module_initialize (module=0x5555555ca340) at p11-kit/modules.c:2640
#17 0x00007ffff7e94d48 in gnutls_pkcs11_add_provider () from /lib/x86_64-linux-gnu/libgnutls.so.30
#18 0x000055555556146e in ?? ()
#19 0x00007ffff7a15b6b in __libc_start_main (main=0x5555555613a0, argc=4, argv=0x7fffffffe638, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fffffffe628) at ../csu/libc-start.c:308
#20 0x0000555555561e2a in ?? ()
(gdb) info threads
  Id   Target Id                                  Frame 
* 1    Thread 0x7ffff75f4d80 (LWP 5968) "p11tool" futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x5555555cbc10)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
  2    Thread 0x7ffff7368700 (LWP 5972) "p11tool" 0x00007ffff7b00729 in __GI___poll (fds=0x7ffff7367cc0, nfds=2, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:29
  3    Thread 0x7ffff6b67700 (LWP 5973) "p11tool" 0x00007ffff7b00729 in __GI___poll (fds=0x7ffff0000c90, nfds=3, timeout=60000)
    at ../sysdeps/unix/sysv/linux/poll.c:29
(gdb) thread 2
[Switching to thread 2 (Thread 0x7ffff7368700 (LWP 5972))]
#0  0x00007ffff7b00729 in __GI___poll (fds=0x7ffff7367cc0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29	../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
(gdb) bt
#0  0x00007ffff7b00729 in __GI___poll (fds=0x7ffff7367cc0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007ffff73a9b0f in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#2  0x00007ffff75ff182 in start_thread (arg=<optimized out>) at pthread_create.c:486
#3  0x00007ffff7b0cb1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) thread 3
[Switching to thread 3 (Thread 0x7ffff6b67700 (LWP 5973))]
#0  0x00007ffff7b00729 in __GI___poll (fds=0x7ffff0000c90, nfds=3, timeout=60000) at ../sysdeps/unix/sysv/linux/poll.c:29
29	in ../sysdeps/unix/sysv/linux/poll.c
(gdb) bt
#0  0x00007ffff7b00729 in __GI___poll (fds=0x7ffff0000c90, nfds=3, timeout=60000) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007ffff73a3446 in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#2  0x00007ffff73a442a in libusb_handle_events_timeout_completed () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#3  0x00007ffff73a451f in libusb_handle_events () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#4  0x00007ffff75d538e in read_thread (param=0x5555555cbb90) at /home/user/pkcs11/cryptoauthlib/third_party/hidapi/libusb/hid.c:827
#5  0x00007ffff75ff182 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6  0x00007ffff7b0cb1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

[rpcme]

@bryan-hunt or @schielimicrochip or @BenUdall-Microchip could you kindly take a look please? I can facilitate on the back end if you like.

[bryan-hunt]

@rpcme & @dspearl-amazon If this is happening 100% of the time after a fresh boot it is a kernel configuration problem. Based on the above it appears it is stuck in the mutex used to ensure process safety - this is an OS component.

That being said if this is not the problem - what is the udev situation? Has the udev rules been updated with something like https://github.com/MicrochipTech/cryptoauthlib/blob/master/lib/hal/90-cryptohid.rules ?

[rpcme]

Bryan - thank you for the assist. On Apr 16, 2020, at 10:26, Bryan Hunt <notifications@github.com> wrote:  @rpcme & @dspearl-amazon If this is happening 100% of the time after a fresh boot it is a kernel configuration problem. Based on the above it appears it is stuck in the mutex used to ensure process safety - this is an OS component. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[dspearl-amazon]

Bryan,
Thanks for your response
The udev rules are in place, and we've reloaded udev/reset the USB hub previously. To be sure, I obtained permission to reboot the server this morning, and it's still hanging. To my knowledge, there's nothing special about our kernel configuration, it's just Ubuntu 19.04

[github-actions]

This issue has been marked as stale - please confirm the issue still exists with the latest version of the library and update the issue if it remains