XHC WHB04B development?
- Finngineering
- Offline
- Premium Member
-
Less
More
- Posts: 110
- Thank you received: 49
01 Mar 2026 06:51 #343680
by Finngineering
Replied by Finngineering on topic XHC WHB04B development?
Okay. Once you get a crash, post the output here and we can try to work it through together. Please ensure that you have some print statement in place of the commented out assert call, so if it fails there, we know about it. Something like:
if(r != 0) {
std::cout << "Usb::setupAsyncTransfer failed with code: " << r << std::endl;
}Please Log in or Create an account to join the conversation.
- Hakan
- Offline
- Platinum Member
-
Less
More
- Posts: 1312
- Thank you received: 449
01 Mar 2026 11:31 - 01 Mar 2026 11:33 #343686
by Hakan
Replied by Hakan on topic XHC WHB04B development?
Got a crash today. Seems to be the usual way. At mode and screen switch.I have seen that libusb debug printout several times before.Attach are the log and also usb.cc and xhc-whb04b6.cc to be able to follow my printouts.
Last edit: 01 Mar 2026 11:33 by Hakan.
Please Log in or Create an account to join the conversation.
- Finngineering
- Offline
- Premium Member
-
Less
More
- Posts: 110
- Thank you received: 49
01 Mar 2026 14:05 #343687
by Finngineering
Replied by Finngineering on topic XHC WHB04B development?
That was unexpected. For all the world, it looks like this get stuck in libusb somewhere. After the "is Open" debug text, the code does the following:
1. Function call XhcWhb04b6Component::enableReceiveAsyncTransfer()
2. From XhcWhb04b6Component::enableReceiveAsyncTransfer() call Usb::setupAsyncTransfer()
3. From Usb::setupAsyncTransfer() call libusb_submit_transfer()
4. From libusb_submit_transfer() call libusb_unref_device()
5. In libusb_unref_device() print "libusb: debug [libusb_unref_device] destroy device"
6. libusb_submit_transfer() never returns is my guess
Maybe some deadlock inside libusb. Whether that would be from some bug in libusb or because of some improper handling in the xhc-whb04b-6 component, I cannot say. At least at the moment. I'll look into it some more, but not right now.
1. Function call XhcWhb04b6Component::enableReceiveAsyncTransfer()
2. From XhcWhb04b6Component::enableReceiveAsyncTransfer() call Usb::setupAsyncTransfer()
3. From Usb::setupAsyncTransfer() call libusb_submit_transfer()
4. From libusb_submit_transfer() call libusb_unref_device()
5. In libusb_unref_device() print "libusb: debug [libusb_unref_device] destroy device"
6. libusb_submit_transfer() never returns is my guess
Maybe some deadlock inside libusb. Whether that would be from some bug in libusb or because of some improper handling in the xhc-whb04b-6 component, I cannot say. At least at the moment. I'll look into it some more, but not right now.
Please Log in or Create an account to join the conversation.
- Finngineering
- Offline
- Premium Member
-
Less
More
- Posts: 110
- Thank you received: 49
02 Mar 2026 11:27 #343723
by Finngineering
Replied by Finngineering on topic XHC WHB04B development?
I made some changes in my firmware so I could generate a disconnect at will. Ten times in a row, I got libusb_submit_transfer to return non-zero in Usb::setupAsyncTransfer. And every time, the pendant reconnected to the xhc-whb04b-6 component without issue. In other words, I am unable to reproduce your issue, which more or less means I cannot help you directly. However, you mentioned that you had to change libusb_init_context() to libusb_init(). It appears libusb_init_context() was introduced in libusb 1.0.27:
libusb.sourceforge.io/api-1.0/group__lib...e12023b7399003c50470
Looking at my system, I have libusb 1.0.28-1. I think it would be well worth trying to upgrade libusb. Or if you don't want to do that, you could use LinuxCNC 2.9.8 as a "live cd" to see if that fixes the issue. This would actually be better, since it's possible that the issue could be in the Linux kernel itself.
libusb.sourceforge.io/api-1.0/group__lib...e12023b7399003c50470
Looking at my system, I have libusb 1.0.28-1. I think it would be well worth trying to upgrade libusb. Or if you don't want to do that, you could use LinuxCNC 2.9.8 as a "live cd" to see if that fixes the issue. This would actually be better, since it's possible that the issue could be in the Linux kernel itself.
Please Log in or Create an account to join the conversation.
- Hakan
- Offline
- Platinum Member
-
Less
More
- Posts: 1312
- Thank you received: 449
02 Mar 2026 13:24 #343728
by Hakan
Replied by Hakan on topic XHC WHB04B development?
I use the built-in 
libusb-1.0 in debian bookworm (12.13)
It says
#define LIBUSB_API_VERSION 0x01000109
in the include file.
I was able to install libusb 1.28, compile xhc component with it and at least it starts.
I have a minimal milling job this afternoon. I'll see how it reacts.
libusb-1.0 in debian bookworm (12.13)It says
#define LIBUSB_API_VERSION 0x01000109
in the include file.
I was able to install libusb 1.28, compile xhc component with it and at least it starts.
I have a minimal milling job this afternoon. I'll see how it reacts.
Please Log in or Create an account to join the conversation.
- Hakan
- Offline
- Platinum Member
-
Less
More
- Posts: 1312
- Thank you received: 449
02 Mar 2026 14:35 #343731
by Hakan
Replied by Hakan on topic XHC WHB04B development?
Exactly the same log message.
I also tested to unplug + plug back the dongle. Exactly the same log message.
Both ended up in the debug message in libusb.
It can of course be my hardware. It isn't to difficult to test with another test computer I have.
I also tested to unplug + plug back the dongle. Exactly the same log message.
Both ended up in the debug message in libusb.
It can of course be my hardware. It isn't to difficult to test with another test computer I have.
Please Log in or Create an account to join the conversation.
- Hakan
- Offline
- Platinum Member
-
Less
More
- Posts: 1312
- Thank you received: 449
02 Mar 2026 19:20 #343744
by Hakan
Replied by Hakan on topic XHC WHB04B development?
Duplicated the setup to a N100 mini-PC.
Couldn't crash the xhc, didn't try for that long though.
So I unplugged the dongle. Put it back.
And it restarted and continued to work. Like magic.
It didn't fail at the usual setupAsyncTransfer, it was somewhere else.
Couldn't crash the xhc, didn't try for that long though.
So I unplugged the dongle. Put it back.
And it restarted and continued to work. Like magic.
It didn't fail at the usual setupAsyncTransfer, it was somewhere else.
Please Log in or Create an account to join the conversation.
- Finngineering
- Offline
- Premium Member
-
Less
More
- Posts: 110
- Thank you received: 49
02 Mar 2026 20:00 #343751
by Finngineering
Replied by Finngineering on topic XHC WHB04B development?
Okay, so maybe we can conclude that somehow the hardware is not 100% suitable on your "real" setup?
If you still test on the N100, I believe you could force the setupAsyncTransfer error by putting the loops back to original values (or even higher), and jogging while a program is running.
If you still test on the N100, I believe you could force the setupAsyncTransfer error by putting the loops back to original values (or even higher), and jogging while a program is running.
Please Log in or Create an account to join the conversation.
- rodw
-
- Offline
- Platinum Member
-
Less
More
- Posts: 11851
- Thank you received: 4015
03 Mar 2026 00:21 #343761
by rodw
Replied by rodw on topic XHC WHB04B development?
Reading something today. Maybe try using smp affinity to lock the USB interrupt to Core1 (away from core 0 housekeeping) and assuming > 2 cores. You can find the interrupt by
cat /proc/interrupts | grep -i usb
Then follow one of the many posts about cpu affinity for networking. Just remember you need to reset this on every boot.
cat /proc/interrupts | grep -i usb
Then follow one of the many posts about cpu affinity for networking. Just remember you need to reset this on every boot.
Please Log in or Create an account to join the conversation.
- Hakan
- Offline
- Platinum Member
-
Less
More
- Posts: 1312
- Thank you received: 449
03 Mar 2026 10:13 - 03 Mar 2026 10:15 #343782
by Hakan
Replied by Hakan on topic XHC WHB04B development?
With loops 100 I easily got a crash.
Unfortunately it dídn't recover. Same old libusb debug message.
This is on the "new" N100 mini pc.
Unfortunately it dídn't recover. Same old libusb debug message.
hal failed to wait for requested mode. waited 500ms
task: main loop took 0.018703 seconds
r = -4 when fail
Failed at 1
transmission failed, try to reconnect ...-4
transmission failed, try to reconnect ...-4
connection lost, cleaning up
libusb_handle_events_timeout_completed done 0
libusb_release_interface done -4
libusb_close done
process done
Done with process()
About to tear down usb
Trying again for 100th time
Started while looooop
After initWhb()
init pausing 3s, waiting for device to be gone ....... done
init usb context ... ok
init not waiting for device XHC-WHB04B-6 vendorId=0x10ce productId=0xeb93, will continue in 0s .... ok
init XHC-WHB04B-6 device found
init detaching active kernel driver ... ok
init claiming interface ... ok
Before mUsb.isDeviceOpen()
is Open
libusb: debug [libusb_unref_device] destroy device 3.8
Shutting down and cleaning up LinuxCNC...
Running HAL shutdown script
Last edit: 03 Mar 2026 10:15 by Hakan.
Please Log in or Create an account to join the conversation.
Time to create page: 0.587 seconds