We've bought this device and have some issues with it:
It's a quad RTL8153 device with an internal usb hub.
ugen0.5: <vendor 0x04b4 product 0x6502> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen0.6: <vendor 0x04b4 product 0x6500> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
ugen0.7: <Realtek USB 10/100/1000 LAN> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA)
ugen0.8: <Realtek USB 10/100/1000 LAN> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA)
ugen0.9: <Realtek USB 10/100/1000 LAN> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA)
ugen0.10: <Realtek USB 10/100/1000 LAN> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA)
It shows up as four ure devices.
After some time plugging/unplugging ethernet cables, one or more of the devices gets stuck in "no carrier" and media: none. At that time, when running "ifconfig", there is a delay in the output between "ether" and the next line ... a few hundred ms I would guess.
ue0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
media: Ethernet autoselect (none <half-duplex>)
status: no carrier
This happens much faster if you put the devices in a lagg, from the increased polling frequency I would guess. Not sure you even need to plug/unplug, may happen from the polling on its own.
Negotiation and link up/down still seems to happen, just not visible from the operating system anymore.
The device is still visible with usbconfig, and doesn't completely disappear. It just seems unresponsive.
There are two patches you can try:
Hi. Tried applying these two patches to releng/13.0 and got a compile error. What branch should I try these against?
cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.subr_epoch.o -MTsubr_epoch.o -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -Wno-format-zero-length -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/kern/subr_epoch.c
/usr/src/sys/kern/subr_epoch.c:489:6: error: no member named 'et_old_priority' in 'struct epoch_tracker'
et->et_old_priority = 0; /* not used */
1 error generated.
*** Error code 1
These patches are for 14-current.
Maybe they will work on the latest 13-stable too.
Applied the patches to latest 13-stable.
Doesn't seem to have improved things much, devices still get stuck occasionally. Nothing fun in dmesg when it happens. Just a link down that doesn't get back up.
If you issue:
usbconfig -d X.Y reset
Where X.Y are the numbers after ugen, does the device come back with the link up?
Yes, that seems to get them going again.