XHC WHB04B development?
- Finngineering
- Offline
- Premium Member
-
Less
More
- Posts: 110
- Thank you received: 49
03 Mar 2026 12:20 #343788
by Finngineering
Replied by Finngineering on topic XHC WHB04B development?
Okay, so probably not hardware related then, after all. I'll try to adjust my test setup a little bit and see if I can reproduce the issue.
Please Log in or Create an account to join the conversation.
- Finngineering
- Offline
- Premium Member
-
Less
More
- Posts: 110
- Thank you received: 49
03 Mar 2026 15:27 #343790
by Finngineering
Replied by Finngineering on topic XHC WHB04B development?
I flashed back the original firmware to my dongle for testing. When commenting out the assert and adding a debug print there instead if r != 0, I get the following output during jogging in auto:I tried more than 10 times in a row, and every time the pendant successfully reconnected. In other words, I cannot reproduce your issue. And unfortunately that also means I cannot be of much help to you.
It is a bit surprising that you get the same issue on two different machines, and I don't. Or are the two machines you tested on fairly similar? Could still be e.g. kernel version difference, I suppose. In case they have fixed some usb bugs related to this. It's a bit of a long shot, but I don't have anything better at the moment.
in 0x04 10 00 00 10 11 00 10 delta 16 => | 04 | 10 | | | 1( 30%) | X( ) | 0 | 10
pndnt wheel event 604
pndnt wheel total counts {counts=604 activeCounter=0 isLeadActive=0}
in 0x04 10 00 00 10 11 06 10 delta 16 => | 04 | 10 | | | 1( 30%) | X( ) | 6 | 10
pndnt wheel event 610
Can't switch mode while mode is AUTO and interpreter is not IDLE
hal failed to wait for requested mode. waited 300ms
pndnt wheel total counts {counts=610 activeCounter=0 isLeadActive=0}
Usb::setupAsyncTransfer() libusb_submit_transfer failed with code -4
transmission failed, try to reconnect ...
transmission failed, try to reconnect ...
connection lost, cleaning up
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
init enabling reception ... ok
in 0x04 10 00 00 10 11 00 10 delta 16 => | 04 | 10 | | | 1( 30%) | X( ) | 0 | 10
pndnt wheel event 610
pndnt wheel total counts {counts=610 activeCounter=0 isLeadActive=0}
task: main loop took 0.036080 seconds
in 0x04 10 00 00 10 11 00 10 delta 16 => | 04 | 10 | | | 1( 30%) | X( ) | 0 | 10
pndnt wheel event 610
pndnt wheel total counts {counts=610 activeCounter=0 isLeadActive=0}It is a bit surprising that you get the same issue on two different machines, and I don't. Or are the two machines you tested on fairly similar? Could still be e.g. kernel version difference, I suppose. In case they have fixed some usb bugs related to this. It's a bit of a long shot, but I don't have anything better at the moment.
Please Log in or Create an account to join the conversation.
- Hakan
- Offline
- Platinum Member
-
Less
More
- Posts: 1311
- Thank you received: 449
05 Mar 2026 14:01 #343894
by Hakan
Replied by Hakan on topic XHC WHB04B development?
I found it.
Ok, I didn't find the reason but I found a way around it.
It always crashed for me with "libusb: debug [libusb_unref_device] destroy device 3.109"
I ran it in the debugger and saw it stopped with a SIGSEGV.
After spending too much time figuring out how to turn on core dumps, I got a core dump.
Here is the stop point.
The one wonders what ctx_log_handler is
I commented out this line in libusb_unref_device()
and then the xhc actually restarted.
Here is the log of that.
Ok, I didn't find the reason but I found a way around it.
It always crashed for me with "libusb: debug [libusb_unref_device] destroy device 3.109"
I ran it in the debugger and saw it stopped with a SIGSEGV.
After spending too much time figuring out how to turn on core dumps, I got a core dump.
Here is the stop point.
The one wonders what ctx_log_handler is
(gdb) p ctx->log_handler
$2 = (libusb_log_cb) 0xbb343c565cbddc86I commented out this line in libusb_unref_device()
and then the xhc actually restarted.
Here is the log of that.
hal failed to wait for requested mode. waited 500ms
pndnt wheel total counts {counts=-353 activeCounter=2 isLeadActive=0}
inTransfer = 0x558412062e00 deviceHandle = 0x558412066360
libusb_fill ..
.. done
Failed in setupAsyncTransfer -4
transmission failed, try to reconnect ...
transmission failed, try to reconnect ...
connection lost, cleaning up
init pausing 10s, 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 ...1 ok
init XHC-WHB04B-6 device found
init detaching active kernel driver ... ok
init claiming interface ... ok
init enabling reception ...In enableReceiveAsyncTransfer
inTransfer = 0x558412062e00 deviceHandle = 0x558412075a50
libusb_fill ..
.. done
ok
in 0x04 10 00 00 0f 13 00 10 delta 15 => | 04 | 10 | | | 0.1( 10%) | Z( ) | \
0 | 10
pndnt wheel event -353Attachments:
Please Log in or Create an account to join the conversation.
- Finngineering
- Offline
- Premium Member
-
Less
More
- Posts: 110
- Thank you received: 49
05 Mar 2026 17:19 #343904
by Finngineering
Replied by Finngineering on topic XHC WHB04B development?
Good job tracking that one down!
Did you previously increase the libusb log level somehow? If so, then maybe that's why it segfaulted for you, but not for me. regardless, looks like a libusb bug to me.
Did you previously increase the libusb log level somehow? If so, then maybe that's why it segfaulted for you, but not for me. regardless, looks like a libusb bug to me.
Please Log in or Create an account to join the conversation.
- Hakan
- Offline
- Platinum Member
-
Less
More
- Posts: 1311
- Thank you received: 449
05 Mar 2026 18:36 #343912
by Hakan
Replied by Hakan on topic XHC WHB04B development?
No, I don't know how to change log level even.
Fresh git clone of libusb1.0, configure and make.
Fresh git clone of linuxcnc.
It has been the same behavior/problem with the libusb-1.0 via apt in debian.
This is a problem since a long time, years.
And this N100 PC is relatively new, latest debian and don't have any history.
Except the linuxcnc config, it is the same.
Hard to find something that sticks out.
I provoked the xhc a bit. Easily crashes with wrong loop setting. But it now recovers after three seconds.
This is a situation I can live with. It would have been better with no crash. Until then, this is fine.
The modification I made was in libusb1.0.
What I see is that if one setthe problem will not appear, the callback function pointed to by context->log_handler will not be called.
Do you know if this can be done in the xhc component code?
It would be good to use std libusb1.0 libs.
Fresh git clone of libusb1.0, configure and make.
Fresh git clone of linuxcnc.
It has been the same behavior/problem with the libusb-1.0 via apt in debian.
This is a problem since a long time, years.
And this N100 PC is relatively new, latest debian and don't have any history.
Except the linuxcnc config, it is the same.
Hard to find something that sticks out.
I provoked the xhc a bit. Easily crashes with wrong loop setting. But it now recovers after three seconds.
This is a situation I can live with. It would have been better with no crash. Until then, this is fine.
The modification I made was in libusb1.0.
What I see is that if one set
context->log_handler = nulltpr;Do you know if this can be done in the xhc component code?
It would be good to use std libusb1.0 libs.
The following user(s) said Thank You: NWE
Please Log in or Create an account to join the conversation.
- Finngineering
- Offline
- Premium Member
-
Less
More
- Posts: 110
- Thank you received: 49
05 Mar 2026 20:21 #343918
by Finngineering
Replied by Finngineering on topic XHC WHB04B development?
I just had a quick look, but might go a bit deeper at another time.
The ctx/context appears to be the libusb_context struct. I guess you could just doafter libusb_init in usb.cc:
github.com/LinuxCNC/linuxcnc/blob/master...whb04b-6/usb.cc#L629
But this probably isn't the best workaround in general.
I guess most of the problems in the past has been because of the assert statement in setupAsyncTransfer? Or did the pendant never reconnect for you in the past? When I was testing and just unplugged the dongle and plugged it back in, it usually didn't fail in the setupAsyncTransfer function, so the assert statement didn't prevent reconnection.
You might also be interested in testing the changes made by Hannes:
github.com/hdiethelm/linuxcnc-fork/tree/xhc-whb04b-6-fix-v2
I believe you need to do a "git checkout xhc-whb04b-6-fix-v2" after git clone in case you want to test that. With regards to the disconnects, his solution is more elegant than decreasing loops, because it avoids trying to change mode altogether when it's clear it would fail anyway.
The ctx/context appears to be the libusb_context struct. I guess you could just do
context->log_handler = nullptr;github.com/LinuxCNC/linuxcnc/blob/master...whb04b-6/usb.cc#L629
But this probably isn't the best workaround in general.
I guess most of the problems in the past has been because of the assert statement in setupAsyncTransfer? Or did the pendant never reconnect for you in the past? When I was testing and just unplugged the dongle and plugged it back in, it usually didn't fail in the setupAsyncTransfer function, so the assert statement didn't prevent reconnection.
You might also be interested in testing the changes made by Hannes:
github.com/hdiethelm/linuxcnc-fork/tree/xhc-whb04b-6-fix-v2
I believe you need to do a "git checkout xhc-whb04b-6-fix-v2" after git clone in case you want to test that. With regards to the disconnects, his solution is more elegant than decreasing loops, because it avoids trying to change mode altogether when it's clear it would fail anyway.
The following user(s) said Thank You: NWE
Please Log in or Create an account to join the conversation.
- Hakan
- Offline
- Platinum Member
-
Less
More
- Posts: 1311
- Thank you received: 449
06 Mar 2026 07:57 - 06 Mar 2026 08:53 #343932
by Hakan
Replied by Hakan on topic XHC WHB04B development?
I tried that already, there is no access to log_handler.
struct libusb_context is not defined, only the pointer to it.
I tried with
in process(), but no change.
There was a new message when restarting the connection from
and that didn't crash even if it uses the same underlying log_v function.
I leave it like that.
The problem has been the assert statement. But I tested to remove that some two years ago
(the github issue) and failed in the same way it does now. But in general the assert is what
people experience, I understood.
I'll test Hannes' version next.
Edit: Tested, it avoids the mode switching altogether. I think that is perfectly fine.
I don't expect to switch to Man mode and jog when I'm running a program. Could happen
by mistake even. If I feel a need to switch to Man I'll designate a button for that.
I have a vague memory I did that on the previous generation xhc.
Is it in a shape to go into linuxcnc repo? I think it should end up there.
struct libusb_context is not defined, only the pointer to it.
I tried with
*mInitCout << "init enabling reception ...";
libusb_set_log_cb(getUsbContext(), nullptr, LIBUSB_LOG_CB_GLOBAL);
libusb_set_log_cb(getUsbContext(), nullptr, LIBUSB_LOG_CB_CONTEXT);
if (!enableReceiveAsyncTransfer())There was a new message when restarting the connection from
core.c: usbi_warn(_ctx, "device %d.%d still referenced",I leave it like that.
The problem has been the assert statement. But I tested to remove that some two years ago
(the github issue) and failed in the same way it does now. But in general the assert is what
people experience, I understood.
I'll test Hannes' version next.
Edit: Tested, it avoids the mode switching altogether. I think that is perfectly fine.
I don't expect to switch to Man mode and jog when I'm running a program. Could happen
by mistake even. If I feel a need to switch to Man I'll designate a button for that.
I have a vague memory I did that on the previous generation xhc.
Is it in a shape to go into linuxcnc repo? I think it should end up there.
Last edit: 06 Mar 2026 08:53 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
06 Mar 2026 15:43 #343944
by Finngineering
Replied by Finngineering on topic XHC WHB04B development?
Yeah, it appears libusb_context is defined in libusbi.h, which is not part of the normal "distribution package". I missed that. There are several compilation defines/options for libusb, which makes a bit more difficult to understand exactly what is happening. But I do think that your libusb_set_log_cb() should have done the trick (unless for some of those compile time options).
It was a little bit strange from the start that it succeeded to print that debug message and only afterwards seemed to hang (which we now know was a segault). I wonder if there could be something wrong with the handling of variadic (=any number of) arguments, which messes up the stack and in the end gives the segfault.
I had a second look at the issue you created a couple of years ago. And yeah, already there you identified libusb as a problem. I don't think really put much thought into that the first time I read it.
Hannes have made a pull request which is waiting to be accepted into LinuxCNC. Andypugh bought a similar pendant and will test the code once he receives the pendant. I guess if he is happy the PR will be accepted. Maybe in 1-2 weeks, is my guess.
I don't think it's possible to switch to manual mode while a program is running or paused. Which is what Hannes version checks for. I presume that if the program is running/paused, it needs to be stopped prior to making the mode change. But I have not verified that. If you are not having a program running/paused, then jogging should change to manual mode.
It was a little bit strange from the start that it succeeded to print that debug message and only afterwards seemed to hang (which we now know was a segault). I wonder if there could be something wrong with the handling of variadic (=any number of) arguments, which messes up the stack and in the end gives the segfault.
I had a second look at the issue you created a couple of years ago. And yeah, already there you identified libusb as a problem. I don't think really put much thought into that the first time I read it.
Hannes have made a pull request which is waiting to be accepted into LinuxCNC. Andypugh bought a similar pendant and will test the code once he receives the pendant. I guess if he is happy the PR will be accepted. Maybe in 1-2 weeks, is my guess.
I don't think it's possible to switch to manual mode while a program is running or paused. Which is what Hannes version checks for. I presume that if the program is running/paused, it needs to be stopped prior to making the mode change. But I have not verified that. If you are not having a program running/paused, then jogging should change to manual mode.
Please Log in or Create an account to join the conversation.
- Hannes
- Offline
- New Member
-
Less
More
- Posts: 14
- Thank you received: 6
06 Mar 2026 22:37 #343963
by Hannes
Replied by Hannes on topic XHC WHB04B development?
Normally, you anyway don't want the program or MDI command to stop because you accidentally jog, so I figured this is a good choice, even if it would switch to manual. Which it doesn't do anyway, at least in my case.
I did not read the whole thread in detail. But it seams you have issues with libusb_submit_transfer() and the assert afterwards? According to the manual, this function is allowed to return disconnected: manpages.debian.org/unstable/libusb2-dev/libusb.3.en.html
This should be fine, we should handle the error, cleanup properly and try to reconnect. Worst case, you have to do is disconnect the dongle and reconnect it again. I can look into that.
Meanwhile, do you have a way to reliably get the device to disconnect? Otherwise, it is always hard to see if a fix is really a fix or just the device behaving nicely for a few hours and then failing again.
@Hakan: I see you have Debian 12 (So libusb 2:1.0.26-1 I guess, libusb-1.0 is the package name, not the exact version). Did you try Debian 13?
@Finngineering:
Which Debian version do you have? Kernel version? Libusb version?
I have Debian 13 stock, libusb 2:1.0.28-1
I did not read the whole thread in detail. But it seams you have issues with libusb_submit_transfer() and the assert afterwards? According to the manual, this function is allowed to return disconnected: manpages.debian.org/unstable/libusb2-dev/libusb.3.en.html
This should be fine, we should handle the error, cleanup properly and try to reconnect. Worst case, you have to do is disconnect the dongle and reconnect it again. I can look into that.
Meanwhile, do you have a way to reliably get the device to disconnect? Otherwise, it is always hard to see if a fix is really a fix or just the device behaving nicely for a few hours and then failing again.
@Hakan: I see you have Debian 12 (So libusb 2:1.0.26-1 I guess, libusb-1.0 is the package name, not the exact version). Did you try Debian 13?
@Finngineering:
Which Debian version do you have? Kernel version? Libusb version?
I have Debian 13 stock, libusb 2:1.0.28-1
Please Log in or Create an account to join the conversation.
- Finngineering
- Offline
- Premium Member
-
Less
More
- Posts: 110
- Thank you received: 49
07 Mar 2026 07:08 #343974
by Finngineering
Replied by Finngineering on topic XHC WHB04B development?
The assert statement is setupAsyncTransfer() is the "big" issue. Simply removing that causes the reconnect to be triggered when trying to send a display update. For me that reconnection works without problems. For Hakan, it gets stuck/segfaults in libusb after reconnect. Somewhere along these lines:
forum.linuxcnc.org/38-general-linuxcnc-q...ment?start=80#343687
It would of course be good to get to the bottom of this. But since I can't reproduce this, it's a bit difficult to debug.
Both myself (with the original firmware) and Hakan can trigger the disconnect reliably by using the original component and jogging while a program is running.
On the development computer, I use the LinuxCNC 2.9.8 iso image / Debian 13. That one has libusb 1.0.28-1. I'm not at that computer right now, so cannot check the kernel version. But it's the stock one from LinuxCNC 2.9.8 iso (unless "apt upgrade" has updated it).
forum.linuxcnc.org/38-general-linuxcnc-q...ment?start=80#343687
It would of course be good to get to the bottom of this. But since I can't reproduce this, it's a bit difficult to debug.
Both myself (with the original firmware) and Hakan can trigger the disconnect reliably by using the original component and jogging while a program is running.
On the development computer, I use the LinuxCNC 2.9.8 iso image / Debian 13. That one has libusb 1.0.28-1. I'm not at that computer right now, so cannot check the kernel version. But it's the stock one from LinuxCNC 2.9.8 iso (unless "apt upgrade" has updated it).
Please Log in or Create an account to join the conversation.
Time to create page: 0.136 seconds