Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

USB: ethernet CDC ECM/EEM support is broken #35338

Closed
aunsbjerg opened this issue May 17, 2021 · 4 comments · Fixed by #35384
Closed

USB: ethernet CDC ECM/EEM support is broken #35338

aunsbjerg opened this issue May 17, 2021 · 4 comments · Fixed by #35384
Assignees
@jfischer-no
Labels
area: Networking area: USB Universal Serial Bus bug The issue is a bug, or the PR is fixing a bug priority: medium Medium impact/importance bug Regression Something, which was working, does not anymore

Comments

@aunsbjerg
Copy link
Collaborator

Describe the bug
When trying to run the echo_server sample with the usbnet overlay, the sample doesn't work as expected. The frdm_k64f/mimxrt1064_evk should appear as a usb ethernet interface in the linux host, but that does not happen.

For the imxrt1064_evk, it becomes entirely unresponsive (no shell activity) after plugging in the second usb cable.

I have tried the usb_hid sample on both boards - both are working as expected.

To Reproduce
Steps to reproduce the behavior:

  1. build:
west build -b frdm_k64f zephyr/samples/net/sockets/echo_server -- \
    -DOVERLAY_CONFIG=overlay-netusb.conf \
    -DCONFIG_NET_IF_MAX_IPV4_COUNT=2 \
    -DCONFIG_NET_IF_MAX_IPV6_COUNT=2 \
    -DCONFIG_USB_DEVICE_NETWORK_LOG_LEVEL_DBG=y
  1. west flash
  2. connect linux host to frdm_k64f/mimxrt1064_evk using second USB port

Expected behavior
According to the USB Device Network guide, the frdm_k64f should show up as a CDC Ethernet Device in dmesg. This does not happen, instead a cdc_ether probe timeout occurs. See dmesg log:

[18571.634996] sd 3:0:0:0: [sda] Attached SCSI removable disk
[18655.135709] usb 1-3: new full-speed USB device number 46 using xhci_hcd
[18655.285111] usb 1-3: New USB device found, idVendor=2fe3, idProduct=0100, bcdDevice= 2.06
[18655.285117] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[18655.285120] usb 1-3: Product: USB-DEV
[18655.285123] usb 1-3: Manufacturer: ZEPHYR
[18655.285126] usb 1-3: SerialNumber: FFFFFFFF4E453886
[18660.404176] cdc_ether: probe of 1-3:1.0 failed with error -110

And the corresponding syslog:

May 17 14:07:22 ARH167 kernel: [18655.135709] usb 1-3: new full-speed USB device number 46 using xhci_hcd
May 17 14:07:22 ARH167 kernel: [18655.285111] usb 1-3: New USB device found, idVendor=2fe3, idProduct=0100, bcdDevice= 2.06
May 17 14:07:22 ARH167 kernel: [18655.285117] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
May 17 14:07:22 ARH167 kernel: [18655.285120] usb 1-3: Product: USB-DEV
May 17 14:07:22 ARH167 kernel: [18655.285123] usb 1-3: Manufacturer: ZEPHYR
May 17 14:07:22 ARH167 kernel: [18655.285126] usb 1-3: SerialNumber: FFFFFFFF4E453886
May 17 14:07:27 ARH167 kernel: [18660.404176] cdc_ether: probe of 1-3:1.0 failed with error -110
May 17 14:07:27 ARH167 mtp-probe: checking bus 1, device 46: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3"
May 17 14:07:27 ARH167 mtp-probe: bus: 1, device: 46 was not an MTP device
May 17 14:07:27 ARH167 mtp-probe: checking bus 1, device 46: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3"
May 17 14:07:27 ARH167 mtp-probe: bus: 1, device: 46 was not an MTP device

And console log for the frdm_k64f:

** Booting Zephyr OS build v2.6.0-rc1-120-g41e885947e4f  ***

[00:00:00.000,000] <dbg> usb_ecm.ecm_interface_config: fixup string 4
[00:00:00.000,000] <inf> usb_dc_kinetis: pre-selected as OUT endpoint
[00:00:00.000,000] <inf> usb_dc_kinetis: pre-selected as IN endpoint
[00:00:00.000,000] <dbg> usb_net.netusb_init: netusb device initialization
[00:00:00.000,000] <inf> usb_net: netusb initialized
[00:00:00.008,000] <inf> usb_dc_kinetis: idx_even 20005abc
[00:00:00.008,000] <inf> usb_dc_kinetis: idx_odd 20005afc
[00:00:00.008,000] <inf> usb_dc_kinetis: idx_even 20005b44
[00:00:00.008,000] <inf> usb_dc_kinetis: idx_odd 20005b84
[00:00:00.008,000] <inf> usb_dc_kinetis: ep 0x0, ep_idx 0
[00:00:00.008,000] <inf> usb_dc_kinetis: ep 0x80, ep_idx 0
[00:00:00.008,000] <inf> net_echo_server_sample: Run echo server
[00:00:00.008,000] <inf> net_echo_server_sample: Waiting for network [1] to be connected
[00:00:00.008,000] <inf> net_echo_server_sample: Waiting for network [2] to be connected
[00:00:00.011,000] <dbg> usb_ecm.ecm_status_cb: USB unhandlded state: 5
[00:00:33.584,000] <inf> usb_dc_kinetis: ep 0x0, ep_idx 0
[00:00:33.584,000] <inf> usb_dc_kinetis: ep 0x80, ep_idx 0
[00:00:33.584,000] <dbg> usb_ecm.ecm_status_cb: USB unhandlded state: 1
[00:00:33.712,000] <inf> usb_dc_kinetis: ep 0x0, ep_idx 0
[00:00:33.712,000] <inf> usb_dc_kinetis: ep 0x80, ep_idx 0
[00:00:33.712,000] <dbg> usb_ecm.ecm_status_cb: USB unhandlded state: 1
[00:00:33.862,000] <inf> usb_dc_kinetis: idx_even 20005bcc
[00:00:33.862,000] <inf> usb_dc_kinetis: idx_odd 20005bdc
[00:00:33.862,000] <inf> usb_dc_kinetis: ep 0x81, ep_idx 1
[00:00:33.862,000] <dbg> usb_ecm.ecm_status_cb: USB unhandlded state: 3
[00:00:33.863,000] <inf> usb_dc_kinetis: idx_even 20005bf4
[00:00:33.863,000] <inf> usb_dc_kinetis: idx_odd 20005c34
[00:00:33.863,000] <inf> usb_dc_kinetis: ep 0x83, ep_idx 3
[00:00:33.863,000] <inf> usb_dc_kinetis: idx_even 20005c7c
[00:00:33.863,000] <inf> usb_dc_kinetis: idx_odd 20005cbc
[00:00:33.863,000] <inf> usb_dc_kinetis: ep 0x2, ep_idx 2
[00:00:33.863,000] <dbg> usb_ecm.ecm_status_cb: USB interface selected
[00:00:33.863,000] <dbg> usb_ecm.ecm_status_interface: iface 1 alt_set 1
[00:00:33.863,000] <dbg> usb_net.netusb_enable: 
[00:00:33.863,000] <dbg> usb_net.netusb_send: Send pkt, len 106
uart:~$ net iface

Interface 0x20002758 (Ethernet) [1]
===================================
Interface is down.

Interface 0x20002840 (Ethernet) [2]
===================================
Link addr : 00:00:5E:00:53:00
MTU       : 1500
Flags     : NO_AUTO_START,IPv4,IPv6
Ethernet capabilities supported:
IPv6 unicast addresses (max 3):
        fe80::200:5eff:fe00:5300 autoconf tentative infinite
IPv6 multicast addresses (max 4):
        ff02::1
IPv6 prefixes (max 2):
        <none>

Impact
It will become a showstopper in a not too distant future. We are planning to use zephyr on a imxrt1064/1024 custom board where USB ethernet will be used to communicate with a host.

Environment (please complete the following information):

  • OS: Ubuntu 20.04.2 LTS
  • Toolchain: Zephyr SDK 0.11.3
  • Commit: Latest master (41e8859)
@aunsbjerg aunsbjerg added bug The issue is a bug, or the PR is fixing a bug area: Networking area: USB Universal Serial Bus platform: NXP NXP labels May 17, 2021
@aunsbjerg
Copy link
Collaborator Author

CC @jfischer-no

@jfischer-no jfischer-no self-assigned this May 17, 2021
@jfischer-no jfischer-no added priority: medium Medium impact/importance bug and removed platform: NXP NXP labels May 17, 2021
@jfischer-no jfischer-no changed the title samples: net: echo_server: usb ethernet not working with frdm_k64f and mimxrt1064_evk samples: net: echo_server: usb ethernet CDC ECM/EEM support is broken May 17, 2021
@jfischer-no jfischer-no changed the title samples: net: echo_server: usb ethernet CDC ECM/EEM support is broken USB: ethernet CDC ECM/EEM support is broken May 17, 2021
@jfischer-no jfischer-no added the Regression Something, which was working, does not anymore label May 17, 2021
@jfischer-no
Copy link
Collaborator

Seems to be caused by f5fb807. Workaround is to build with -DCONFIG_NET_TC_TX_COUNT=1

@aunsbjerg
Copy link
Collaborator Author

Seems to be caused by f5fb807. Workaround is to build with -DCONFIG_NET_TC_TX_COUNT=1

Thank you for looking into this so quickly.
Can confirm workaround works on both boards. Will keep issue open until a more permanent fix is found.

jfischer-no added a commit to jfischer-no/zephyr that referenced this issue May 18, 2021
@jfischer-no
net: enable TX thread if USB device support is enabled
6b8d2af 
Without TX thread support in network stack USB device stack
blocks it self by usb_transfer_sync() which is
called in the same context as usb_set_interface() in sequence
of netusb_enable(), net_if_up(), net_l2_send().

Fixes: zephyrproject-rtos#35338

Signed-off-by: Johann Fischer <[email protected]>
@jfischer-no jfischer-no mentioned this issue May 18, 2021
Merged
@jfischer-no
Copy link
Collaborator

Without queuing in network stack the USB stack blocks it self by usb_transfer_sync() and do not respond to SetInterface request.
This is due to the bad design in USB device stack at various points, but I currently do not see a simple solution as #35384.

usb_set_interface()
    netusb_enable()
        net_if_up()
            ...
                net_l2_send()
                    ...
                        usb_transfer_sync()

galak pushed a commit that referenced this issue May 18, 2021
@jfischer-no @galak
net: enable TX thread if USB device support is enabled
21b3609 
Without TX thread support in network stack USB device stack
blocks it self by usb_transfer_sync() which is
called in the same context as usb_set_interface() in sequence
of netusb_enable(), net_if_up(), net_l2_send().

Fixes: #35338

Signed-off-by: Johann Fischer <[email protected]>
andvib pushed a commit to andvib/zephyr that referenced this issue May 31, 2021
@jfischer-no @nvlsianpu
[nrf fromtree] net: enable TX thread if USB device support is enabled
410b807 
Without TX thread support in network stack USB device stack
blocks it self by usb_transfer_sync() which is
called in the same context as usb_set_interface() in sequence
of netusb_enable(), net_if_up(), net_l2_send().

Fixes: zephyrproject-rtos#35338

Signed-off-by: Johann Fischer <[email protected]>
(cherry picked from commit 21b3609)
Signed-off-by: Andrzej Puzdrowski <[email protected]>
jori-nordic pushed a commit to jori-nordic/zephyr that referenced this issue Jun 15, 2021
@jfischer-no @mbolivar-nordic
[nrf fromtree] net: enable TX thread if USB device support is enabled
653e406 
Without TX thread support in network stack USB device stack
blocks it self by usb_transfer_sync() which is
called in the same context as usb_set_interface() in sequence
of netusb_enable(), net_if_up(), net_l2_send().

Fixes: zephyrproject-rtos#35338

Signed-off-by: Johann Fischer <[email protected]>
(cherry picked from commit 21b3609)
Signed-off-by: Andrzej Puzdrowski <[email protected]>
(cherry picked from commit 410b807)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jfischer-no jfischer-no

Labels
area: Networking area: USB Universal Serial Bus bug The issue is a bug, or the PR is fixing a bug priority: medium Medium impact/importance bug Regression Something, which was working, does not anymore
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

net: enable TX thread if USB device support is enabled jfischer-no/zephyr
2 participants
@aunsbjerg @jfischer-no