https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234668
Bug ID: 234668
Summary: RealTek 8168/8111 can no longer transfer large files
Product: Base System
Version: 12.0-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: misc
Assignee: b...@freebsd.org
Reporter: ch...@zang.com
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
options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
ether bc:5f:f4:2c:f3:2e
inet 192.168.235.4 netmask 0xffffff00 broadcast 192.168.235.255
inet 192.168.235.30 netmask 0xffffffff broadcast 192.168.235.30
inet 192.168.235.31 netmask 0xffffffff broadcast 192.168.235.31
inet 192.168.235.32 netmask 0xffffffff broadcast 192.168.235.32
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
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.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
