Bug 234668 - RealTek 8168/8111 can no longer transfer large files
Summary: RealTek 8168/8111 can no longer transfer large files
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 12.0-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-net (Nobody)
Keywords: regression
Depends on:
Reported: 2019-01-06 17:30 UTC by Chad R
Modified: 2019-01-09 15:49 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Chad R 2019-01-06 17:30:02 UTC
I upgraded from 11.0 to 12.0 and since then have been unable to transfer large files TO the host, though sending files from that host is unaffected.

I've attempted file xfer via scp, rsync and cifs and in each case the file transfer starts, gets a few megabytes in, and then stalls, with the bandwidth-counters wuickly falling to zero. There are no errors reported via e.g. netstat -I, and nothing in the logs. Here's the dmesg for the interface:

% cat /var/run/dmesg.boot |grep re0
re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0xa000-0xa0ff mem 0xd2104000-0xd2104fff,0xd2100000-0xd2103fff irq 17 at device 0.0 on pci12
re0: Using 1 MSI-X message
re0: Chip rev. 0x2c000000
re0: MAC rev. 0x00200000
miibus0: <MII bus> on re0
re0: Using defaults for TSO: 65518/35/2048
re0: Ethernet address: aa:bb:cc:dd:ee:ff
re0: netmap queues/slots: TX 1/256, RX 1/256
re0: link state changed to DOWN
re0: link state changed to UP

And here's ifconfig:

% ifconfig re0
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether bc:5f:f4:2c:f3:2e
	inet netmask 0xffffff00 broadcast 
	inet netmask 0xffffffff broadcast 
	inet netmask 0xffffffff broadcast 
	inet netmask 0xffffffff broadcast 
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active

This is the only interface on the host.

Attempted debugging:
 - removed bridge0 and tap0
 - moved physical switch ports
 - sysctl net.inet.ip.redirect=0
 - sysctl net.link.ether.inet.allow_multicast=1
 - attempted to limit bandwidth used with 'scp -l <val>', and for low values (1024, 2048, 4096...) I would get a 'stall' message after a couple of seconds, but then scp would recover and proceed normally (albeit slowly); I would terminate after 2 minutes of transfer just because I dont have all day, but saw no further stall messages. This worked fine through 131072. At '-l 262144' scp was unable to recover from the stall.