Libcomposite USB Ethernet devices stopped working with 5.x kernels

[hardillb]

Describe the bug
When using a Raspberry Pi (Pi Zero or Pi 4) as a USB ECM Ethernet device (a USB Gadget not a host) the Pi starts correctly and sets up usb0 device. The device enumerates correctly on the host device (testing with a Ubuntu 18.04 laptop) and passes enough data to do a DHCP handshake but then no other data is passed after the IP address is assigned

To reproduce

• Build a SD card image using https://github.com/hardillb/rpi-gadget-image-creator (This script takes a standard raspbian image and boots it under qemu, installs dnsmasq and then adds some scripts and config files using expect). Easy enough to do the same by hand if needed.
• connect Pi Zero or Pi4 to usb port on host machine (USB-C on the Pi 4 or the left most micro usb socket on Pi Zero)
• Allow to boot and then try ssh pi@10.55.0.1 (pi should hand out addresses in the 10.55.0.1/255.255.255.248 range to the host)

Expected behaviour
Pi should enumerate as a Ethernet device and the link should be stable.

Actual behaviour
Pi enumerates but the Ethernet link but very little data is passed

System
Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:

• Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW
  PiZeroW (but also on Pi4 & PiZero)
• Which OS and version (cat /etc/rpi-issue)?
  Raspberry Pi reference 2020-08-20
  Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 9a3a10bf1019ebb2d59053564dc6b90068bad27d, stage2
• Which firmware version (vcgencmd version)?
  Aug 19 2020 17:40:15
  Copyright (c) 2012 Broadcom
  version e90cba19a98a0d1f2ef086b9cafcbca00778f094 (clean) (release) (start)
• Which kernel version (uname -a)?
  Linux raspberrypi 5.4.51+ I2c1_baudrate being overridden by i2c.conf in 25-Feb-2016 distribution #1333 Mon Aug 10 16:38:02 BST 2020 armv6l GNU/Linux
  Logs
  If applicable, add the relevant output from dmesg or similar.

Additional context
I get same behaviour if I upgrade to the latest available kernel

[pelwell]

Has this ever worked? If so, in which kernel version?

[hardillb]

Yes, it works with all the 4.9.x kernel based raspbian buster builds. I'll get you an exact kernel version when I get back home

[aallan]

Can confirm, this used to work.

[pelwell]

4.9? I hope you find something more recent...

[hardillb]

Works on 4.19.97+ from the 2020-02-13-raspbian-buster-lite.img

[pelwell]

Thanks - that's something to work with.

[hardillb]

This might help narrow things down https://gist.github.com/geekman/5bdb5abdc9ec6ac91d5646de0c0c60c4#gistcomment-3441665

[pelwell]

Can you explain where the sudden interest has come from? If the breakage occurred between 4.9 and 4.14, why has the problem only just been noticed? Or is the link not as relevant as you suggested it might be?

[hardillb]

The link was only because they appeared to have narrowed down the change more closely, if that's misleading I apologise, it definitely works with 4.19.97

The interest is because I had to rebuild a SD card recently and noticed it didn't work, combined with the magpi article about my instructions on how to set this up is likely to lead to a LOT more people trying this and it just not working.

But also this is an obvious regression, it used to work its now broken, that should be good enough.

[pelwell]

It's working for me on 5.4.51+ - I'm getting ~105Mb/s throughput using iperf -c <server> -d. The host is a 4B running dnsmasq to allocate the dhcp addresses, the client is a Zero running a script to bring up the ethernet and serial gadgets, then dhclient usb1. ssh is also fine.

[pelwell]

@aallan Can you confirm that it no longer works?

[aallan]

I can try and find some time tomorrow to test.

[urbanserj]

I hit the same issue with usb linux gadget on linux 5.4 and reported it in "Moving Linux Kernel to 5.4" thread, both, g_* and usb libcomposite, are broken. Please see kernel backtraces in this comment, I got them via UART. rpi-update e1050e94821a70b2e4c72b318d6c6c968552e9a2 installs 4.19.118 which works just fine.

BTW, I had the same issue with a sunxi-based board on latest debian build of linux 5.4.