Ethernet media autoselect results in 10baseT connection

D

DarkLord

I have a network card using the re driver, and up until recently it has pretty much worked quite well without me messing with it for the past few years. However, lately my speeds have seen a notable decrease, and while trying to figure out why, I realized that when I look at the ifconfig output, it is autoselecting 10baseT/UTP <full-duplex>. This would explain why my speedtest is capping out in the 9 Mbps range, but I've had much faster connections in the past so I'm not sure why all of a sudden it is selecting the wrong media type.

I changed the media type manually in my rc.conf
Code: 
ifconfig_re0="DHCP"
ifconfig_re0_ipv6="inet6 accept_rtadv media 1000baseT mediaopt full-duplex"

But this seems to cause the interface to flap (oscillate between link state UP and DOWN) and makes the connection unusable. It did seem to work for a little bit at one point, but the connection was still slower than it should have been (speedtest giving me 30Mbps instead of over 100). After more experimenting, going back to those settings now just result in the flapping.

If I leave the interface to autoselect, with my rc.conf in the original configuration
Code: 
ifconfig_re0="DHCP"
ifconfig_re0_ipv6="inet6 accept_rtadv"
I do notice that it seems to flap for a little bit before finally ending up at the 10baseT/UTP media setting. It starts at the 1000baseT media selection, then the link goes down, so it selects 100baseT, goes down, selects 10baseT, and stays there.

I also booted into the windows partition and was able to get speeds over 200Mbps, so I don't think it's a cable problem or that the network card is dead.

Any ideas for what might be wrong or what I should try?
 
There is a history with Realtek RT8111/8168 chips being poorly supported.
https://forums.freebsd.org/threads/replacing-realtek-re-driver.55861/

Realtek has a official driver for FreeBSD verison 7 and 8 and has not released anything since.
I have found that the earlier chip versions work better on stock FreeBSD driver. Specifically 8168C, 8168D, and 8168E.
Its the newer ones that are problems. 8168G and 8168H in my experience.
Edit:
**Note I am not recommending you compile a driver but wanted to show the history involved. That said under Realtek FreeBSD 7 and 8 it shows files updated on 8-18. So recent activity. What version they are using is beyond me.**
 
Windows is the cause. Start to FreeBSD from a cold boot, it should work, but if you start Windows and then reboot to FreeBSD the card will only work at 10baseT speeds.

It's because the Windows driver sets something in the hardware(power saving, wol,etc) that persists after reboot and prevents FreeBSD from correctly detecting the card.
 
Criosphinx said:
Windows is the cause. Start to FreeBSD from a cold boot, it should work, but if you start Windows and then reboot to FreeBSD the card will only work at 10baseT speeds.
Click to expand...
Thanks for the advice. I had actually cold booted into FreeBSD this time, but I've definitely had a failed windows update in the past mess up the network card across boots so I decided to examine this possibility a little more. Turns out this time it wasn't a failed update, it appears an update probably changed one of the network interface settings in windows and led to this behaviour.

I experimented with a few values, and turning off energy efficient ethernet for the interface in windows ended up fixing it. Interestingly, before I changed this setting in windows, I had also booted into a Fedora live cd and it had no problems with network access, so it seems like it should be possible for FreeBSD to handle this case. Maybe if I have time I'll take a look at the code over the holidays and see if I can figure something out. Device drivers have always seemed like they would be fun to learn about.
 
You could also check the output of sysctl -a | grep eee to see if there's a tunable that can be set on loader.conf to disable it. Several nic drivers include that option.
 
phoenix said:
You could also check the output of sysctl -a | grep eee to see if there's a tunable that can be set on loader.conf to disable it.
Click to expand...
When I run that, I see an entry like this
Code: 
hw.em.eee_setting: 1
I assume that is only relevant to the em driver though, right? So the lack of an entry for re means it probably does not exist for this driver. Nice to know about that possibility though!
 
You must log in or register to reply here.
Back
Top