Created attachment 222292 [details] if_ure.c and if_urereg.h patch Could you add support for Realtek RTL8153B, RTL8156 and RTL8156B ? I tried doing it by studying openbsd and linux drivers, but since i'm not a developer, i certainly made some rookie mistakes.
jmg@ is currently working on this driver. Please synchronize with him. --HPS
Just wanted to express interest into this. I'm way over my head looking at the proposed patch and realy not competent to compile it, but I'm fairly familiar with linux comand line, will get around to learning the freebsd specialties which I find much simpler, so I'm available to test it out on my current opnSense installs running 12.1-RELEASE-p13-HBSD (hardened) with my USB RTL8156B and my ISP's box providing 2.5G ethernet.
RTL8156 will be supported by the cdce driver on 13.0-RELEASE. You can try on 13.0-BETAs/RCs.
(In reply to Masachika ISHIZUKA from comment #3) I haven't compared performance of this patch with what if_cdce delivers, but 13.0-RELEASE's performance is not what I expected. I have a USB dongle with RTL8156B chipset that easily gets 1.9 Gbps or 2.3 Gbps with iPerf3 when attached to a recent Apple laptop. FreeBSD added a USB quirk for the device to select profile 2. The device then gets 92 Mbps throughput. If I switch it back to profile 1 using usbconfig -d ugen0.12 set_config 1, it gets roughly 800 Mbps. The switch says the port negotiated to 2.5 Gbps in either case. Is there a way to achieve closer to linerate performance?
Hi, I think jmg@ is working on something. Last update from him was that the Realtek devices disconnect from USB if stressed too much, and this is a severe problem. --HPS
(In reply to Masachika ISHIZUKA from comment #3) Hi. Any news about RTL8153B support? About one week ago I tried 13-CURRENT on NanoPi R2S and it wasn't detected :(
(In reply to Hans Petter Selasky from comment #5) jmg@ said he is not working actively on it. Hans, can you work on it when you get a chance? thanks,
Yes, I'll have a look at this.
If you could upload an update for the if_ure.4 manual page, that would be great! Submitted to -current with some minor changes. See following commit message. --HPS
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=d4cf41a99b405c73288aea81e3c4580d1de18435 commit d4cf41a99b405c73288aea81e3c4580d1de18435 Author: Hans Petter Selasky <hselasky@FreeBSD.org> AuthorDate: 2021-06-04 08:28:58 +0000 Commit: Hans Petter Selasky <hselasky@FreeBSD.org> CommitDate: 2021-06-04 08:29:55 +0000 Add support for RTL8153B, RTL8156 and RTL8156B to if_ure(4). Submitted by: fbbz@synack.eu PR: 253374 MFC after: 1 week Sponsored by: Mellanox Technologies // NVIDIA Networking sys/dev/usb/net/if_ure.c | 965 ++++++++++++++++++++++++++++++++------------ sys/dev/usb/net/if_urereg.h | 200 ++++++++- 2 files changed, 890 insertions(+), 275 deletions(-)
It seems NanoPI R2S still has issue with it: ugen0.2: <Realtek USB 10/100/1000 LAN> at usbus0 ure0 on uhub3 ure0: <Realtek USB 10/100/1000 LAN, class 0/0, rev 3.00/31.00, addr 1> on usbus0 ure0: timeout waiting for chip autoload ure0: timeout waiting for phy to stabilize ure0: MAC assigned randomly ure0: attaching PHYs failed ure0: unknown version 0x0000 usbconfig: ugen0.2: <Realtek USB 10/100/1000 LAN> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA)
More debug messages: ure0: timeout waiting for phy to stabilize ure0: timeout waiting for OOB control ure0: timeout waiting for OOB control ure0: MAC assigned randomly ure0: attaching PHYs failed
Is this a regression issue, or a new one. What does: usbconfig -d X.Y dump_device_desc say? --HPS
It may not be a regression, but something could be missing for 8153b. ugen0.2: <Realtek USB 10/100/1000 LAN> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0300 bDeviceClass = 0x0000 <Probed by interface class> bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0009 idVendor = 0x0bda idProduct = 0x8153 bcdDevice = 0x3100 iManufacturer = 0x0001 <retrieving string failed> iProduct = 0x0002 <retrieving string failed> iSerialNumber = 0x0006 <retrieving string failed> bNumConfigurations = 0x0002
Can you also dump the configuration descriptor, I see there are two configurations there. usbconfig -d X.Y dump_all_config_desc --HPS
ugen0.2: <Realtek USB 10/100/1000 LAN> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0039 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x0000 <no string> bmAttributes = 0x00a0 bMaxPower = 0x0024 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0003 bInterfaceClass = 0x00ff <Vendor specific> bInterfaceSubClass = 0x00ff bInterfaceProtocol = 0x0000 iInterface = 0x0000 <no string> Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 <IN> bmAttributes = 0x0002 <BULK> wMaxPacketSize = 0x0400 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Additional Descriptor bLength = 0x06 bDescriptorType = 0x30 bDescriptorSubType = 0x03 RAW dump: 0x00 | 0x06, 0x30, 0x03, 0x00, 0x00, 0x00 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 <OUT> bmAttributes = 0x0002 <BULK> wMaxPacketSize = 0x0400 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Additional Descriptor bLength = 0x06 bDescriptorType = 0x30 bDescriptorSubType = 0x03 RAW dump: 0x00 | 0x06, 0x30, 0x03, 0x00, 0x00, 0x00 Endpoint 2 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0083 <IN> bmAttributes = 0x0003 <INTERRUPT> wMaxPacketSize = 0x0002 bInterval = 0x0008 bRefresh = 0x0000 bSynchAddress = 0x0000 Additional Descriptor bLength = 0x06 bDescriptorType = 0x30 bDescriptorSubType = 0x00 RAW dump: 0x00 | 0x06, 0x30, 0x00, 0x00, 0x02, 0x00
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=dab84426a68d43efaede62ccf86ca3ef852f8ae3 commit dab84426a68d43efaede62ccf86ca3ef852f8ae3 Author: Hans Petter Selasky <hselasky@FreeBSD.org> AuthorDate: 2021-06-04 13:48:15 +0000 Commit: Hans Petter Selasky <hselasky@FreeBSD.org> CommitDate: 2021-06-04 13:51:01 +0000 Narrow down the probe range for if_ure(4) compatible devices to only match the first vendor specific interface, if any. PR: 253374 MFC after: 1 week Sponsored by: Mellanox Technologies // NVIDIA Networking sys/dev/usb/net/if_ure.c | 7 ++++--- sys/dev/usb/usb.h | 1 + 2 files changed, 5 insertions(+), 3 deletions(-)
root@generic:~ # usbconfig ugen2.1: <DWCOTG OTG Root HUB> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.1: <Synopsys XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen4.1: <Generic OHCI root HUB> at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen3.1: <Generic EHCI root HUB> at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.2: <Realtek USB 10/100/1000 LAN> at usbus0, cfg=255 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) and usbconfig -d 0.2 reset makes it attach and work: root@generic:~ # usbconfig -d 0.2 reset ure0: at uhub3, port 2, addr 1 (disconnected) ure0: timeout waiting for phy to stabilize ure0: timeout waiting for phy to stabilize ure0: MAC assigned randomly ure0: attaching PHYs failed ure0: detached ure0 on uhub3 ure0: <Realtek USB 10/100/1000 LAN, class 0/0, rev 3.00/31.00, addr 1> on usbus0 root@generic:~ # ure0: MAC assigned randomly miibus1: <MII bus> on ure0 rgephy2: <RTL8251/8153 1000BASE-T media interface> PHY 0 on miibus1 rgephy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto root@generic:~ #
(In reply to Ganbold Tsagaankhuu from comment #18) Do I need something special for USB support to work? I tried 14-CURRENT with u-boot 2021.04 and only have those visible: root@generic:~ # usbconfig ugen2.1: <Generic EHCI root HUB> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.1: <DWCOTG OTG Root HUB> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen3.1: <Generic OHCI root HUB> at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) root@generic:~ # uname -a FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n247271-597cc550e7b: Thu Jun 10 07:44:44 UTC 2021 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
(In reply to sec from comment #19) You need to plug a USB device. Sometimes a FDT GPIO configuration update is required to make sure your USB port is really connected and has +5V. --HPS
(In reply to Hans Petter Selasky from comment #20) Hm, so I plugged USB mouse into the other port - it's visible, but still no ure interface :)
A little update (thanks Ganbold for help). What I was missing was this line: fdt_overlays="rk3328-dwc3" in /boot/loader.conf Then after boot, errors were the same, so: usbconfig -d 0.2 reset did the trick. Setting cpu.freq to 1200 is getting: dwc0 around 350mbit/s ue0 around 300mbit/s which is not bad, but under openwrt it was getting 800-900mbit/s
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=47c5e288eee94c67369443d0ed7c2ab21235c924 commit 47c5e288eee94c67369443d0ed7c2ab21235c924 Author: Hans Petter Selasky <hselasky@FreeBSD.org> AuthorDate: 2021-06-04 13:48:15 +0000 Commit: Hans Petter Selasky <hselasky@FreeBSD.org> CommitDate: 2021-07-10 19:17:29 +0000 Narrow down the probe range for if_ure(4) compatible devices to only match the first vendor specific interface, if any. PR: 253374 Sponsored by: Mellanox Technologies // NVIDIA Networking (cherry picked from commit dab84426a68d43efaede62ccf86ca3ef852f8ae3) sys/dev/usb/net/if_ure.c | 7 ++++--- sys/dev/usb/usb.h | 1 + 2 files changed, 5 insertions(+), 3 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=77f7133bd55c3f6a73b6428ceaa8c266940a55f3 commit 77f7133bd55c3f6a73b6428ceaa8c266940a55f3 Author: Hans Petter Selasky <hselasky@FreeBSD.org> AuthorDate: 2021-06-04 08:28:58 +0000 Commit: Hans Petter Selasky <hselasky@FreeBSD.org> CommitDate: 2021-07-10 19:17:26 +0000 Add support for RTL8153B, RTL8156 and RTL8156B to if_ure(4). Submitted by: fbbz@synack.eu PR: 253374 Sponsored by: Mellanox Technologies // NVIDIA Networking (cherry picked from commit d4cf41a99b405c73288aea81e3c4580d1de18435) sys/dev/usb/net/if_ure.c | 965 ++++++++++++++++++++++++++++++++------------ sys/dev/usb/net/if_urereg.h | 200 ++++++++- 2 files changed, 890 insertions(+), 275 deletions(-)
(In reply to sec from comment #22) A couple of observations: if one adds error logging to the read/write functions in ure, the error it gets back is USB_ERR_IOERROR (18). Not quite helpful as it will continue for-ever trying to do stuff so console scrolls badly. Initially it comes up as stated above without iManufacturer, ... strings but with bNumConfigurations = 0x0002 and only one (1) Configuration index 0 and no Configuration index 1. As also stated, after the device reset, both the strings, and 2nd config index show up and the errors also go away. I have not yet managed to trace this on a bus; I need to remove the device from the kernel config for that. I keep wondering however which specific bit the ure device reset triggers in the USB stack on XHCI/ubus/uhub/.. which would make this come up and work? Are there any hints on what one could speculate on to possibly speed debugging up?
Hi Bjoern, If you can investigate this, probably using a USB analyzer, it would be great. There are different ways USB devices can respond to error: IOERROR is a combination of multiple hardware related errors, CRC, BABBLE and more. You would need to dig out the XHCI completion status code and look that up in the XHCI specification PDF file. Getting the exact error code first, might shed some light into what is actually going on there. STALL is the only error code which indicate the device is still OK. TIMEOUT is software only. --HPS
(In reply to Hans Petter Selasky from comment #26) Thanks Hans; I'll go digging. This is very helpful. (In reply to Bjoern A. Zeeb from comment #25) And to reply for people using the r2s, I can provoke the situation by toggling gpioctl -f /dev/gpioc2 -t 22 # pin 22: 1 PC6<OUT> to 0 ; which is USB3.0-EN if I am not mistaken. When the device comes up the pin is enabled so that shouldn't be the problem and VDD-5V should be supplied.
Hey all, What's the current progress on this? I just read that the framework laptop's future Ethernet expansion card will be using an RTL8156 chipset, so I'm expecting an increased usage of this driver on FreeBSD (including myself): https://frame.work/products/ethernet-expansion-card - Jonathan
Yesterday I was able to do a quick install of FreeBSD 13.1-RELEASE and tested the support for the Framework Ethernet expansion card. The good news is that I was able to get an IPv4 address from my router with no issues via DHCP (I think I also was able to get an IPv6 one, but I didn't check). I also didn't see the constant interface up/down that I see when using my Anker dongle's Ethernet port over USB-C either (the framework Ethernet expansion card is RJ-45 but runs over Type-C). The bad news is that it doesn't seem to be very performant. On a fresh join on the box into my Syncthing cluster, I observed a maximum performance of 10 MiB down, sustained. On Linux with the same exact hardware, the Ethernet card gave me 98-99 MiB down, sustained.
Is your USB hooked up via thunderbolt? Can you check the pciconf -lv ? --HPS
Created attachment 237387 [details] pciconf -lv (framework laptop ethernet expansion)
Attached is the pciconf -vl results on 13.1-RELEASE. I'm building 14-CURRENT atm. Those results are with my anker dongle attached (hdmi/power/usb keyboard receiver/usb mouse receiver) all going through it into a Type-C port expansion card on the framework (so that's connected to the machine over a Type C connection as well since all the adapter slots are "type c" as well). The ethernet cable is connected to the new framework ethernet expansion card (which is also connected to the machine via type c). The machine also has 2 unused usb3 type a ports. Nothing else connected.
Created attachment 237389 [details] pciconf -lv on 14-CURRENT main-n258626-865f46b2555 I can confirm that the speeds are also 10-11 MiB/s on 14-CURRENT main-n258626-865f46b2555.
The XHCI controllers in Framework laptops apparently have some issues. I got one of those supposedly broken USB's in my hands and they work just fine on my computers ... Is it possible to test the dongle, if external, on another Intel, AMD or for that sake RPI4? I currently suspect there is a bug in the XHCI driver space and not in the if_ure driver itself. Maybe Linux has some quirks ... --HPS
> pciconf -lv (framework laptop ethernet expansion) Yep, it's thunderbold. Maybe the BIOS is doing something wrong, because we don't have a real driver for thunderbolt yet. Maybe that's the issue. All I've got for thunderbolt is here: https://github.com/hselasky/usb4 --HPS
Thanks Hans. The dongle works fine on Mac OS (my work computer) and on Windows and Linux. I only tested the Ethernet expansion on framework but I used it on both Linux and FreeBSD on this machine, it works fine on Linux (98-99 MiB/s down). This is a related ticket for the dongle https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255251 The expansion card doesn't have that up/down interface issue, it's just much slower than the Linux counterpart.
I forgot to mention that my dongle happens to also be using a realtek chip as well: ure0 on uhub3 ure0: <Realtek USB 10/100/1000 LAN, class 0/0, rev 2.10/30.00, addr 4> on usbus1 miibus0: <MII bus> on ure0 rgephy0: <RTL8251/8153 1000BASE-T media interface> PHY 0 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto ue0: <USB Ethernet> on ure0 ue0: Ethernet address: a0:ce:c8:d3:ca:0a Also, given that all four expansion slots on the framework are all Type C, prioritizing support for the XHCI driver may automatically fix other issues with all of the framework expansion cards since they all use the same interface.
bugmeister would like to thank Hans Petter for his years of ports maintenance and his work on FreeBSD in general. May he rest in peace. An in-memoriam can be read at https://lists.freebsd.org/archives/freebsd-announce/2023-July/000076.html With hat: bugmeister