Project

General

Profile

Actions
Copy link

Bug #3870

closed

re(4) NICs on APU are unable to hardcode speed/duplex properly

Added by Jim Pingle over 10 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Chris Buechler
Category:
Interfaces
Target version:
2.2
Start date:
09/18/2014
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:
All

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

Actions
Copy link
 #1

Updated by Jim Thompson about 10 years ago

Do we know if this is a problem with 2.1 or 2.2, (or both)?

Actions
Copy link
 #2

Updated by Jim Pingle about 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.

Actions
Copy link
 #3

Updated by Chris Buechler about 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.

Actions
Copy link
 #4

Updated by Chris Buechler about 10 years ago

  • Affected Architecture All added
  • Affected Architecture deleted (amd64)
Actions
Copy link
 #5

Updated by Chris Buechler about 10 years ago

  • Affected Version changed from 2.2 to All
Actions
Copy link
 #6

Updated by Chris Buechler about 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.

Actions
Copy link
 #7

Updated by Chris Buechler about 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.

Actions
Copy link
 #8

Updated by Chris Buechler about 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.

Actions
Copy link
 #9

Updated by → luckman212 about 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)

Actions
Copy link
 #10

Updated by Chris Buechler about 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.

Actions
Copy link
 #11

Updated by Chris Buechler about 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.

Actions
Copy link
 #12

Updated by Tanmay Chaudhry almost 9 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

Actions
Copy link

Also available in: Atom PDF