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 about 10 years ago. Updated over 8 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

Also available in: Atom PDF