Forum Menu

XHC WHB04B development?

More
7 months 4 weeks ago #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.

More
7 months 4 weeks ago #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:
Code:
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}
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.

Please Log in or Create an account to join the conversation.

More
7 months 3 weeks ago #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
Code:
(gdb) p ctx->log_handler $2 = (libusb_log_cb) 0xbb343c565cbddc86

I commented out this line in libusb_unref_device()
 
and then the xhc actually restarted.
Here is the log of that.
Code:
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 -353
 

Please Log in or Create an account to join the conversation.

More
7 months 3 weeks ago #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.

Please Log in or Create an account to join the conversation.

More
7 months 3 weeks ago #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 set
Code:
context->log_handler = nulltpr;
the 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.
 
The following user(s) said Thank You: NWE

Please Log in or Create an account to join the conversation.

More
7 months 3 weeks ago #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 do 
Code:
context->log_handler = nullptr;
after 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 following user(s) said Thank You: NWE

Please Log in or Create an account to join the conversation.

Time to create page: 0.103 seconds
Powered by Kunena Forum