Bug 256675

Summary: [usb] [if_ure] device gets stuck in link down after a few linkup/linkdown events
Product: Base System Reporter: Erik Inge Bolsø <knan-bfo>
Component: usbAssignee: freebsd-usb (Nobody) <usb>
Status: New ---    
Severity: Affects Only Me CC: hselasky
Priority: ---    
Version: 13.0-RELEASE   
Hardware: Any   
OS: Any   

Description Erik Inge Bolsø 2021-06-17 15:33:38 UTC
We've bought this device and have some issues with it:

https://www.dustinhome.no/product/5011204717/adapter-usb-30-4-x-gigabit-lan

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
        options=68009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        ether 00:e0:4c:68:9b:67
        media: Ethernet autoselect (none <half-duplex>)
        status: no carrier
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>


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.
Comment 1 Hans Petter Selasky freebsd_committer 2021-06-17 16:45:04 UTC
Hi,

There are two patches you can try:

https://reviews.freebsd.org/D30376
https://reviews.freebsd.org/D28136

--HPS
Comment 2 Erik Inge Bolsø 2021-06-21 12:30:00 UTC
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
Comment 3 Hans Petter Selasky freebsd_committer 2021-06-21 12:40:35 UTC
These patches are for 14-current.

Maybe they will work on the latest 13-stable too.

--HPS
Comment 4 Erik Inge Bolsø 2021-06-22 10:18:19 UTC
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.
Comment 5 Hans Petter Selasky freebsd_committer 2021-06-22 12:15:44 UTC
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?

--HPS
Comment 6 Erik Inge Bolsø 2021-06-22 13:02:15 UTC
Yes, that seems to get them going again.