I was recently testing the supplied framework USB-C to Ethernet adaptor card (transparent one) with the AMD Framework. I get frequent disconnects and resets of the BUS leading to flapping of the NIC. This is particularly problematic when i.e running Firmware updates to connected routers etc (I encountered it when running tftp flash).
The behavior is more stable when the expansion card is in the back right expansion slot.
I also have never been able to achieve reasonable speeds from this NIC chipset. Even when connected at 2.5Gbit with a 10G capable 803.bz port on a switch I am only able to push sub 930mbit transfers through the adapter.
I have collected dmesg and journal output. But am wondering if others are seeing the same terrible performance from the supplied NIC. I am a bit disapointed, as in my collection of dozens of USB NIC adapters this is by far the flakiest I have encountered and leaves me wishing there was a real PHY MAC breakout on the FW.
Conversly Thunderbolt networking at 20GBit seems fine over the rear ports. But that’s not helpful when you need an RJ45.
It might be worth reaching out to Support about this! I’ve got the same NIC, roughly the same laptop, on Linux and Windows and I can readily push 2300MBit – even on the left ports – reliably.
Thanks for the reference point. This is with an 6.7rc kernel and firmware blobs from next ; so it’s possible it’s something in an update. What is your working kernel version / distro-blob combination so I can test?
This may be bug worthy. Haven’t tested it recently on Fedora, mostly Ubuntu, so it would be interesting to do some comparison testing with older kernels, see if the behavior reflects similar there.
I know you how to do this stuff, so I look forward to seeing what you find and I will then circle back for my own testing on 6.6.6-200 - seriously though, thank you very much for pushing on this with the RC kernel. It’s greatly appreciated.
Yeah it’s on my list of things to circle back on over x-mas. Will get you some actual metrics from flent/iperf3 and similar once I’ve got a bit of time.
Sounds like @DHowett was mentioning windows - which I believe likely works fine RTL are particularly well known for having opaque driver stacks in linux, but are well known for having badly documented quirks (lots of examples from Openwrt experience with their switch SoC’s)
I’ve been using the slightly out-of-date 6.5 series (6.5.13 at the most recent) on Debian unstable. It hasn’t reported loading any firmware–nor do I seem to have any on disk (!).
can you post the modinfo output of r8152 as well as the ethtool and ethtool -K
rtl drivers often don’t ship seperate firmware but rely on a heap of ‘magic’ init inside the driver itself - if you look at the r8152.c directly you’ll see random blobs to init things which is typical realtek.
ethtool +/- -k (assumption: you wanted show-features, not to set features)
Settings for enx9cbf0d002427:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
2500baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Full
Auto-negotiation: on
Port: MII
PHYAD: 32
Transceiver: internal
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00007fff (32767)
drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
Link detected: yes
Features for enx9cbf0d002427:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: on
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: on
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-tunnel-remcsum-segmentation: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
tx-gso-list: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
rx-gro-list: off
macsec-hw-offload: off [fixed]
rx-udp-gro-forwarding: off
hsr-tag-ins-offload: off [fixed]
hsr-tag-rm-offload: off [fixed]
hsr-fwd-offload: off [fixed]
hsr-dup-offload: off [fixed]
In the meantime, I’ve restarted testing after pulling rtl8156b-2.fw from Debian unstable. (Sorry, grabbed the wrong binary earlier.)
