Page MenuHomeFreeBSD

ure: fix spurious link flaps from MII
Needs ReviewPublic

Authored by rkitover_gmail.com on Fri, Mar 6, 1:27 AM.
Referenced Files
F147008952: D55682.id173248.diff
Sat, Mar 7, 1:45 PM
F146980170: D55682.id173252.diff
Sat, Mar 7, 7:38 AM
F146969201: D55682.id173261.diff
Sat, Mar 7, 6:00 AM
F146969159: D55682.id173261.diff
Sat, Mar 7, 6:00 AM
F146959709: D55682.id173252.diff
Sat, Mar 7, 3:41 AM
F146922210: D55682.id173264.diff
Fri, Mar 6, 7:18 PM
F146922090: D55682.id.diff
Fri, Mar 6, 7:16 PM
F146919301: D55682.id173249.diff
Fri, Mar 6, 6:38 PM
Subscribers

Details

Reviewers
adrian
kevlo
Group Reviewers
USB
network
Summary

A race condition in the MII layer causes spurious link down events, see:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252165

. In statchg, on link down, check if the PHY reports the link as
actually down using the BMSR register, if not, force the status of the
link to back up and restart TX. Do the same in a MII linkchg handler.

On actual link up, restart TX in case it went idle and down.

I have tested this patch with a Realtek 8153 USB interface, and it fixes
the link flaps.

Signed-off-by: Rafael Kitover <rkitover@gmail.com>

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 71213
Build 68096: arc lint + arc unit

Event Timeline

Remove frozen TX fix, only needed for axge

pouria added inline comments.
sys/dev/usb/net/if_ure.c
562

style.9

Unfortunately, even after applying your patch, I still have the issue:

% mdo tail -n 500 /var/log/messages | grep -E 'ue0|8153'
Mar  7 00:57:55 cornelia kernel: rgephy0: <RTL8251/8153 1000BASE-T media interface> PHY 0 on miibus0
Mar  7 00:57:55 cornelia kernel: ue0: <USB Ethernet> on ure0
Mar  7 00:57:55 cornelia kernel: ue0: Ethernet address: 00:e0:4c:a4:4e:ef
Mar  7 00:57:55 cornelia kernel: ue0: link state changed to DOWN
Mar  7 00:58:16 cornelia kernel: ue0: link state changed to UP
Mar  7 01:01:44 cornelia kernel: ue0: link state changed to DOWN

usbconfig:

ugen0.14: <RTL8153 Gigabit Ethernet Adapter Realtek Semiconductor Corp.> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (28mA)

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0320
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 = 0x0007  <retrieving string failed>
bNumConfigurations = 0x0002

Also, shortly after plugging in the usb dock, ifconfig ue0 takes about ~2 seconds to respond with the media status:

% time ifconfig ue0
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:a4:4e:ef
media: Ethernet autoselect (none <half-duplex>)
status: no carrier
nd6 options=823<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,STABLEADDR>
ifconfig ue0  0.00s user 0.01s system 0% cpu 1.687 total

The initial link flaps on device initialization is not fixed by this patch, but, if you run with and without the patch for like an hour or two, you will see the difference.

I don't know about the ifconfig slowness, may be MII related, I will investigate.

Despite the Ethernet port being connected, after replugging in the USB dock it reports that ue0 is DOWN, even though the Ethernet lights are on and the other Ethernet endpoint reports connected and UP:

% mdo tail -f /var/log/messages
Mar  7 01:20:09 cornelia kernel: ugen0.11: <GenesysLogic USB3.1 Hub> at usbus0
Mar  7 01:20:09 cornelia kernel: uhub3 on uhub0
Mar  7 01:20:09 cornelia kernel: uhub3: <GenesysLogic USB3.1 Hub, class 9/0, rev 3.20/6.63, addr 18> on usbus0
Mar  7 01:20:09 cornelia kernel: uhub3: 4 ports with 4 removable, self powered
Mar  7 01:20:10 cornelia kernel: ugen0.12: <Realtek USB 10/100/1000 LAN> at usbus0
Mar  7 01:20:10 cornelia kernel: ure0 on uhub3
Mar  7 01:20:10 cornelia kernel: ure0: <Realtek USB 10/100/1000 LAN, class 0/0, rev 3.20/31.00, addr 19> on usbus0
Mar  7 01:20:10 cornelia kernel: miibus0: <MII bus> on ure0
Mar  7 01:20:10 cornelia kernel: rgephy0: <RTL8251/8153 1000BASE-T media interface> PHY 0 on miibus0
Mar  7 01:20:10 cornelia kernel: rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
Mar  7 01:20:10 cornelia kernel: ue0: <USB Ethernet> on ure0
Mar  7 01:20:10 cornelia kernel: ue0: Ethernet address: 00:e0:4c:a4:4e:ef
Mar  7 01:20:10 cornelia kernel: ue0: link state changed to DOWN
Mar  7 01:20:10 cornelia kernel: ugen0.13: <GenesysLogic USB2.1 Hub> at usbus0
Mar  7 01:20:10 cornelia kernel: uhub4 on uhub0
Mar  7 01:20:10 cornelia kernel: uhub4: <GenesysLogic USB2.1 Hub, class 9/0, rev 2.10/6.63, addr 20> on usbus0
Mar  7 01:20:11 cornelia kernel: uhub4: 4 ports with 4 removable, self powered

Despite the Ethernet port being connected, after replugging in the USB dock it reports that ue0 is DOWN, even though the Ethernet lights are on and the other Ethernet endpoint reports connected and UP:

And now, after about eight minutes, ue0 suddenly reports that it's up.

Mar  7 01:28:17 cornelia kernel: ue0: link state changed to UP

The initial link flaps on device initialization is not fixed by this patch, but, if you run with and without the patch for like an hour or two, you will see the difference.

I don't know about the ifconfig slowness, may be MII related, I will investigate.

I'm not expert in usb driver. I just want to help by testing it.

Can you please verify which behaviors happen for you with and without the patch?