Francois SIMEREY

It's not a recent question, but I've got the same issue. The problem is the UDIM sequence of the texture which do not respect the standard UDIM naming.
For example:
- XXX_panels_BaseColor.1101.exr
- XXX_panels_BaseColor.1102.exr
- XXX_panels_BaseColor.1103.exr
- XXX_panels_BaseColor.1104.exr

are not a UDIM standard. So it's working with Karma CPU but not with Karma XPU.
The solution is to change UV to other place inside a correct UDIM naming.
In this case, you can offset by -10.0 all vertices with uv.y > 9, and renaming these 4 textures by 1001,1002,1003 and 1004.exr

You can do this via a COP. Inside your FBX Subnetwork:
1. create a COP2 Network
2. Inside, create a File COP
3. copy / past the path found in materials created by houdini, something like this .fbm/xxxxx.png
4. export with a ROP File Output

You must do this for each texture map, diffuse, bump / normal etc …
So it could be a lot of work for a complex model. A python script would be useful to do this automatically.

HongMao
So it appears the real problem is with the OpenSSL library that comes with the Houdini instillation. The final step that seems to have fixed everything is by copying Manjaro's libssl.so.1.0.0, libcrypto.so.1.0.0, and libz.so.1 from /usr/lib, to Houdini's dsolib directory, overwriting Houdini's versions of those same .so files. But I also hope this story might help other Linux artists who want their Houdini 16 to work again…

Thanks for this trick, it's working but starting houdini take a lot of time, more than one minute !
For info, i replaced libz.so.1.0.7 by the libz.so.1.0.11 from /usr/lib/ and relinked the other libz.XX
I'm under Manjaro (i3wm) with the last nvidia driver from manjaro, 375.66