Bug #3870
closedre(4) NICs on APU are unable to hardcode speed/duplex properly
0%
Description
The APU uses re(4) network interfaces. If one of these is configured to a specific speed/duplex such as 100BaseTX <full-duplex>, it is unable to properly obtain the configured speed to a switchport configured for the same hardcoded speed.
The media output when configured for this state shows that it's actually running at half-duplex, which is what is typically seen when negotiation with the switch fails:
media: Ethernet 100baseTX <full-duplex> (100baseTX <half-duplex>)
This happens on both 2.1.x and 2.2, and has been confirmed on multiple APU devices and multiple switches.
There may not be much we can do for it if it's a deficiency of the NIC itself, but the [[https://www.freebsd.org/cgi/man.cgi?query=re&apropos=0&sektion=4&manpath=FreeBSD+10.0-RELEASE&arch=default&format=html re(4)]] man page says it should support forcing speed and duplex.
NIC details:
re1@pci0:2:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x06 hdr=0x00
class = network
subclass = ethernet
bar [10] = type I/O Port, range 32, base 0x2000, size 256, enabled
bar [18] = type Memory, range 64, base 0xfe700000, size 4096, enabled
bar [20] = type Prefetchable Memory, range 64, base 0xfe600000, size 16384, enabled
re1: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0x2000-0x20ff mem 0xfe700000-0xfe700fff,0xfe600000-0xfe603fff at device 0.0 on pci2
re1: Using 1 MSI-X message
re1: ASPM disabled
re1: Chip rev. 0x2c000000
re1: MAC rev. 0x00200000
miibus1: <MII bus> on re1
Updated by Jim Thompson almost 10 years ago
Do we know if this is a problem with 2.1 or 2.2, (or both)?
Updated by Jim Pingle almost 10 years ago
I've tried both 2.1.x and 2.2 and they are both affected. It's not possible to set the speed/duplex on either one.
Updated by Chris Buechler almost 10 years ago
- Status changed from New to Confirmed
This has always been an issue on at least some (and I believe most, if not all) re(4), dating back to at least the FreeBSD 6.x days, confirmed through at least 10.1.
Updated by Chris Buechler almost 10 years ago
- Affected Architecture All added
- Affected Architecture deleted (
amd64)
Updated by Chris Buechler almost 10 years ago
- Affected Version changed from 2.2 to All
Updated by Chris Buechler almost 10 years ago
- Assignee set to Chris Buechler
I'll try this on Linux to see how that behaves, should help narrow down whether it's hardware or driver.
Updated by Chris Buechler almost 10 years ago
Either OpenBSD has the same problem, or this is a hardware issue.
# uname -a OpenBSD flashrd 5.6 FLASHRD#7 amd64
default, both ends on auto.
media: Ethernet autoselect (1000baseT full-duplex)
re2 on auto, switch forced to 100 full
media: Ethernet autoselect (100baseTX half-duplex)
re2 and switch forced to 100 full
media: Ethernet 100baseTX full-duplex (100baseTX half-duplex)
Exact same behavior. Having trouble getting a Linux distro to boot on the APU, will get results from there as well.
Updated by Chris Buechler almost 10 years ago
Linux much happier on SD card in the APU, couldn't get anything to boot from USB flash.
TLDR version: either the hardware is broken, or Linux, OpenBSD and FreeBSD are all broken.
root@OpenWrt:~# uname -a Linux OpenWrt 3.10.49 #3 Wed Oct 1 17:09:35 CEST 2014 i686 GNU/Linux
Switch and eth2 on auto.
root@OpenWrt:~# ethtool eth2 Settings for eth2: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) drv probe ifdown ifup Link detected: yes
As expected, gigabit. Change switch port to forced 100 full, disabling autoneg.
root@OpenWrt:~# ethtool eth2 Settings for eth2: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Link partner advertised link modes: 100baseT/Half Link partner advertised pause frame use: No Link partner advertised auto-negotiation: No Speed: 100Mb/s Duplex: Half Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) drv probe ifdown ifup Link detected: yes
As expected, 100 half. This shows the switch is no longer doing autonegotiation.
Force eth2 to 100 full as well:
# ethtool -s eth2 speed 100 duplex full
and it ends up at 100 half.
root@OpenWrt:~# ethtool eth2 Settings for eth2: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 100baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Link partner advertised link modes: 100baseT/Half Link partner advertised pause frame use: No Link partner advertised auto-negotiation: No Speed: 10Mb/s Duplex: Half Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) drv probe ifdown ifup Link detected: yes
Oddly, it actually shows 10 Mb/s half duplex there. That's definitely not correct, it's at 100 Mb. It can iperf at 100 Mb wire speed pulling in. Pushing out is more like 20 Mbps, which shows there definitely is a duplex mismatch there.
Updated by → luckman212 almost 10 years ago
Boy I sure hope this is somehow fixable in software - we have a fair handful of APUs deployed already and continue to buy new ones weekly. If this turns out to be an unfixable hardware problem it's going to potentially be quite a headache. Some broadband vendors require us to lock ports at 100/Full or 1000/full and I am afraid we've already been "bitten" by this issue (although at the time I didn't know about this bug so I naturally blamed the carrier's equipment)
Updated by Chris Buechler almost 10 years ago
I contacted Pascal @ PC Engines to see if that's an issue they're aware of and if they have any further info on it.
Autonegotiation is mandatory for 1000BT, "forcing" something to gigabit just prevents it from negotiating anything other than gigabit. It doesn't disable autonegotiation, so that's a non-issue. It's a problem at 10 or 100 Mb.
Updated by Chris Buechler almost 10 years ago
- Status changed from Confirmed to Closed
PC Engines not aware of the issue, but not surprised by it given Realtek's horrible documentation.
We've confirmed it's a problem in the hardware with the above testing, outside our ability to fix.
Updated by Tanmay Chaudhry over 8 years ago
Hi,
I was also effected by this bug, also had it pegged down as a hardware issue, but it's not. I switched to IPFire(linux) and negotiated manually, it does work.
The only difference was that I ran
ethtool -s eth0 autoneg off ethtool -s eth0 speed 100 duplex full
So, I had to manually specify to not auto negotiate and it works fine.
Hardware = APU1D4 Running Ipfire core98
Settings for red0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: Not reported Advertised pause frame use: No Advertised auto-negotiation: No Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: off Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) drv probe ifdown ifup Link detected: yes