D-Link Gigabit NIC DGE-528T stuck at 100Mbps

[umarti22]

Hi

I've had to replace the onboard LAN port (Realtek chip) of my PC. Replacement is a PCI Gigabit NIC from D-Link using the Realtek 8169S chip, Model DGE-528T.

Problem is, I can't get the new DGE-528T to connect at full speed. It is only using 100baseTX full-duplex, and 1000baseT isn't even available on the interface for manual configuration. According to pciconf the NIC is detected correctly:
class=0x020000 card=0x43001186 chip=0x43001186 rev=0x10 hdr=0x00
(vendor='D-Link System Inc' device='DGE-528T Gigabit Ethernet Adapter').

whereas dmesg shows rather generic info:
re0: <Realtek PCI GBE Family Controller> port ...
re0: Using Memory Mapping!
re0: Using line-based interrupt
re0: version:1.95.00
re0: Ethernet address: 00:ad:24:xx:xx:xx
<some patent info>
re0: Ethernet address 00:ad:24:xx:xx:xx

The onboard LAN port with some Realtek chip too (also re0:, so same driver) used to be able to use 1000baseT link speed.

Are there any settings where I can influence the link speed and settings available to this NIC? Do I need to activate or make a new entry for this specific model in some configuration file?

I have checked other forums where a possible solution to such problems was patching the driver module sources and recompiling the sources, which seems to be not an option here since there are no sources that came with the installation.

I would be grateful for any hints, so I don't need to go back to the store and try to replace the card again...

[hawkraptor]

Okay, I know this is an ancient post but I just struggled with this same issue on two DGE-560 PCIe Ethernet cards for the past 3 days, and I finally got it working. tl;dr at the bottom.

The main difference I've found between our cards is that the DGE-528 should be using the Realtek re(4) drivers, whereas the DGE-560 card should be using the Marvell/SysKonnect msk(4) drivers.

My initial mistake was thinking that since my cards weren't auto-negotiating 1000baseT, that the correct drivers weren't being loaded and it was using some provisional driver that only worked properly at 100BaseTX. This turned out to be only partially true.

I tried loading the msk driver into the kernel, building the msk and miibus .ko files and placing them in /boot/kernel/, using kldload to load the driver modules, and kept getting messages that the drivers were already loaded. This made less and less sense to me since in my mind, the right drivers couldn't possibly be loaded, since it wasn't auto-negotiating at gigabit speed, only fast ethernet.

What finally made it click for me was realizing that my adapter names showing in OPNsense (also when I ran ifconfig) were showing as re0 and re1, then stumbling across this unanswered forum post, and realizing that for some reason at boot time I was seeing a message for RealTek Network boot. I took another look in the kernel and realized that the re(4) driver was also being loaded.

On a wild whim I decided "Heck it, what could disabling one of these drivers in the kernel possibly break?"
Dangerous, I know, but I commented the device line for the re driver in a custom kernel config, thinking that if my card is really supposed to be using the msk driver, than that's the only one I want present.

First I had to download subversion to clone the source onto my system. This isn't quite supported by OPNSense, and some further research is making it look like I possibly could have just used the kldunload command to remove the re(4) driver:

https://www.cyberciti.biz/tips/freebsd-how-to-unload-remove-device-driver-module-from-kernel.html
I haven't tried this so I don't know how well it will work.

But, I wasn't aware of using kldunload, so I went the route of re-building the kernel, which on OPNSense is a pain and probably not advised.
First I had to add the following into the package repositories in /usr/local/etc/pkg/repos/freebsd.conf (not advised according to https://docs.opnsense.org/manual/software_included.html#the-ports-tree):

'FreeBSD:
{
url: "http://pkg.FreeBSD.org/${ABI}/latest"                                                                                               
} '

Then I ran 'pkg update'  to update and 'pkg install subversion' to install subversion so I could clone the source code into /usr/src/ according to Section A.3 of the FreeBSD documentation:
https://www.freebsd.org/doc/handbook/svn.html

First I installed the ca_root_nss  package: 'pkg install ca_root_nss'
Then I checked out the source. It seems like OPNSense doesn't come with a copy of the FreeBSD source, so I did a full checkout as opposed to an update of /usr/src/:
'svn checkout https://svn.freebsd.org/base/releng/11.2 /usr/src/'
You can run 'uname-r' to get the BSD version, currently OPNSense is on 11.2 afaik.

Once that was done I made a copy of, configured, and built my custom kernel according to sections 8.4 and 8.5 in the FreeBSD documentation:
https://www.freebsd.org/doc/handbook/kernelconfig-config.html
https://www.freebsd.org/doc/handbook/kernelconfig-building.html
to copy the generic kernel I used 'cp GENERIC MYKERNEL' and edited with nano after I installed it, because I like nano. You can use 'ee MYKERNEL' if you want to use the built-in text editor.

I disabled the re device driver by just adding "#" at the beginning of the line reading "device re"
I built and installed the kernel using:

'make buildkernel KERNCONF=MYKERNEL'

'make installkernel KERNCONF=MYKERNEL'

where "MYKERNEL" is the name I gave my copied, custom kernel

I rebooted and lo and behold, my $10 Ethernet cards were finally running at 1000baseT full-duplex, just as Marvell and SysKonnect intended. Additionally, my onboard LAN port doesn't seem to have been affected, and is still present and auto-negotiating 1000baseT according to ifconfig.

In your case, for the DGE-528 you may have to switch it around and disable the msk driver in the kernel (leave the miibus driver in place), but I don't know since I haven't used that card. I'm guessing based on the fact that the re driver page references that card specifically (see link in 2nd paragraph).

I wonder if it could be that both cards have related chipsets depending on their hardware revision, but one being a PCI card and one being a PCIe card causes them to conflict. I don't know, but I got it working so I'm finally a bit happier. If you or anyone else happens to come across this and is struggling with a similar issue on similar hardware, hopefully this may help you too. Thank you for coming to my TED talk.

tl;dr
My Gigabit DGE-560 only negotiated at 100baseTX when both the re(4) and msk(4) drivers were present in the kernel. Disabled re(4) driver in kernel, rebuilt, and cards now auto-negotiate 1000baseT full-duplex.

EDIT: the kernel update to 20.1.7 seems to have undone the work and my adapters reverted back to 100baseT.
I had to rebuild my custom kernel again and I thought I rebooted successfully through the UI, but that still didn't fix it. Not sure if the UI reboot actually powers off the system since SSH hadn't kicked me out.
To be safe I copied the msk.ko driver file I built from /usr/src/sys/modules/msk/ to /boot/kernel/ and then rebooted, and that kicked it back into place.