if_re driver problem with RealTek 8169 AND 8139 cards

Hi everyone.

I didn't post it before just because nobody seem to have ever had this problem, so... I figured it must be something about my hardware?

Anyway. Just as I had it in 8.1-RELEASE I still have it after upgrading to 8.2-RELEASE.
I have two NICs:
1. RealTek 8169 on my motherboard (ASUS P5B)
2. RealTek 8139 in my PCI slot.

The problem is, 8169 doesn't work with the original if_re driver, only 8139 does. But my ISP's cable is inserted into 8169. It shows up OK, gets recognized OK, but... when I give command
Code:
dhclient re0
it says
Code:
re0: no link .............. giving up
and the NIC's LEDs give no light either, as though there was REALLY no link.

As I mentioned, it didn't work in 8.1, it still doesn't work in 8.2.
Is it because I have both cards installed simultaneously? I don't know; didn't try to remove one of them and try again.

How did I handle it? Well I found a VERY dirty fix, because there was really no other. I downloaded a MUCH earlier version of the driver source (the file was called rtl_bsd_drv_v179), here is the version information found in the C file):
Code:
$FreeBSD: src/sys/pci/if_rl.c,v 1.38.2.7 2001/07/19 18:33:07 wpaul Exp $
and found out that this particular one works fine with 8169 yet doesn't work with 8139.
So, as I'm no C language expert, I just deleted all the 8139 definitions from the source file, edited other source files accordingly and now I use it for my 8169 card as a replacement if_re.ko. It works fine regardless the RELEASE version. And for 8139 I use the shipped if_rl.ko, which works fine for that particular card.

Things described above make a VERY dirty fix, everyone will agree this is not the way to go. But I found NO information about anyone to ever have had this problem, as though it only exists in my strange world :/...

And NO, I don't have any such problem in any of the OS's I'm using: both NICs work fine in Windows XP, Solaris, various Linux distros.
 
It's confusing trying to figure out what you did. Sounds like the 8139 works fine.

You patched an old version of if_rl to work with the 8169?

Please file a PR. There have been some other problems with the re(4) driver, and this might be related.
 
Well the old if_rl originally DID work for 8169, but it didn't for 8139. And the new if_rl works fine for 8139, while .
And if_re, perhaps, works for something else, but not for 8169 in my configuration anyway.

So I just created 2 versions of if_rl, which I named correspondingly if_rl8139 and if_rl8169. I think I just removed /usr/src/sys/modules/re directory altogether and in the /usr/src/sys/modules/rl I have two versions of if_rl.c and header files.

In the old if_rl.c I just removed all the definitions for 8139 based cards from there.
Here is what I left of the device definitions:
Code:
static struct rl_type rl_devs[] = {
	{ RT_VENDORID, RT_DEVICEID_8169,
		"Realtek PCI GBE Family Controller" },
	{ RT_VENDORID, RT_DEVICEID_8169SC,
		"Realtek PCI GBE Family Controller" },
	{ RT_VENDORID, RT_DEVICEID_8168B,
		"Realtek PCIe GBE Family Controller" },
	{ RT_VENDORID, RT_DEVICEID_8101E,
		"Realtek PCIe FE Family Controller" },
	{ ACCTON_VENDORID, ACCTON_DEVICEID_5030,
		"Accton MPX 5030/5038 10/100BaseTX" },
	{ DLINK_VENDORID, DLINK_DEVICEID_530TXPLUS,
		"D-Link DFE-530TX+ 10/100BaseTX" },
	{ 0, 0, NULL }
};
So I took care there was no mentioning left of 8139, and with this sort of edit the resulting driver don't give a damn about 8139, nor about the corresponding code which is called once 8139 chip is detected. In the Makefile I called it if_rl8169.ko.
There were trifling compilation problems:
Code:
cc1: warnings being treated as errors
/usr/src/sys/modules/rl/../../pci/if_rl8169.c:200: warning: pointer type mismatch in conditional expression
*** Error code 1
which were resolved by removing "-Werror" parameter from the cc command. Then I did
Code:
kldload /$path_to/if_rl8169.ko
and here, the new rl0 device can see the link OK. Fine!
Code:
rl0: <Realtek PCIe GBE Family Controller> port 0xb800-0xb8ff mem 0xfe9ff000-0xfe9fffff irq 19 at device 0.0 on pci3
rl0: version:1.79
rl0: Ethernet address: 00:1a:92:03:f4:b3

This product is covered by one or more of the following patents: US5,307,459, US5,434,872, US5,732,094, US6,570,884, US6,115,776, and US6,327,625.
rl0: Ethernet address: 00:1a:92:03:f4:b3
rl0: [ITHREAD]
and ifconfig:
Code:
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:1a:92:03:f4:b3
        inet 95.84.237.139 netmask 0xfffffc00 broadcast 95.84.239.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active


And the current if_rl, I think, I didn't modify at all. It looks like this:
Code:
static struct rl_type rl_devs[] = {
	{ RT_VENDORID, RT_DEVICEID_8129, RL_8129,
		"RealTek 8129 10/100BaseTX" },
	{ RT_VENDORID, RT_DEVICEID_8139, RL_8139,
		"RealTek 8139 10/100BaseTX" },
	{ RT_VENDORID, RT_DEVICEID_8139D, RL_8139,
		"RealTek 8139 10/100BaseTX" },
	{ RT_VENDORID, RT_DEVICEID_8138, RL_8139,
		"RealTek 8139 10/100BaseTX CardBus" },
	{ RT_VENDORID, RT_DEVICEID_8100, RL_8139,
		"RealTek 8100 10/100BaseTX" },
	{ ACCTON_VENDORID, ACCTON_DEVICEID_5030, RL_8139,
		"Accton MPX 5030/5038 10/100BaseTX" },
	{ DELTA_VENDORID, DELTA_DEVICEID_8139, RL_8139,
		"Delta Electronics 8139 10/100BaseTX" },
	{ ADDTRON_VENDORID, ADDTRON_DEVICEID_8139, RL_8139,
		"Addtron Technology 8139 10/100BaseTX" },
	{ DLINK_VENDORID, DLINK_DEVICEID_530TXPLUS, RL_8139,
		"D-Link DFE-530TX+ 10/100BaseTX" },
	{ DLINK_VENDORID, DLINK_DEVICEID_690TXD, RL_8139,
		"D-Link DFE-690TXD 10/100BaseTX" },
	{ NORTEL_VENDORID, ACCTON_DEVICEID_5030, RL_8139,
		"Nortel Networks 10/100BaseTX" },
	{ COREGA_VENDORID, COREGA_DEVICEID_FETHERCBTXD, RL_8139,
		"Corega FEther CB-TXD" },
	{ COREGA_VENDORID, COREGA_DEVICEID_FETHERIICBTXD, RL_8139,
		"Corega FEtherII CB-TXD" },
	{ PEPPERCON_VENDORID, PEPPERCON_DEVICEID_ROLF, RL_8139,
		"Peppercon AG ROL-F" },
	{ PLANEX_VENDORID, PLANEX_DEVICEID_FNW3603TX, RL_8139,
		"Planex FNW-3603-TX" },
	{ PLANEX_VENDORID, PLANEX_DEVICEID_FNW3800TX, RL_8139,
		"Planex FNW-3800-TX" },
	{ CP_VENDORID, RT_DEVICEID_8139, RL_8139,
		"Compaq HNE-300" },
	{ LEVEL1_VENDORID, LEVEL1_DEVICEID_FPC0106TX, RL_8139,
		"LevelOne FPC-0106TX" },
	{ EDIMAX_VENDORID, EDIMAX_DEVICEID_EP4103DL, RL_8139,
		"Edimax EP-4103DL CardBus" }
};
only in the Makefile I called its name if_rl8139.ko.
But now that I've upgraded to 8.2-RELEASE, the shipped if_rl.ko works fine for 8139 card.

Therefore, for 8169 I'm using a modified older version of if_rl.ko, and for 8139 the modern one works fine.
Thanks to the way it is handled in FreeBSD model, kernel has no complains whatsoever against these two drivers. There were some trifling compilation problems, which were easily resolved.

I will file a PR now.
Thanks!
 
Oh, forgot to mention. For the old driver version I also used the old if_rlreg.h from the old version. I placed it into the /usr/src/sys/pci and renamed to if_rlreg8169.h accordingly, and also reflected this in the Makefile.

So there wasn't a lot of "patching" to be done, and I'm afraid it will be of little help to those who're working on the if_re.ko driver, as I made NO modifications to the code itself because I don't understand it. I only prevented the old version from interfering with 8139 NIC, which it couldn't handle properly anyway.
 
And since I described it thus far, let me define the package I used.
You can Google for rtl_bsd_drv_v179 driver package and it will be found on one of those "free-driverdownload" sites or other.
In the Readme it says, that
Code:
This driver is modified by Realtek Semiconductor corp. and it has been tested OK
on FreeBSD 4.7, FreeBSD v5.1, FreeBSD v5.4, FreeBSD v6.0, and FreeBSD v7.2.
 
I can't comment on vendor's driver and don't know what's going on there. If 8.2-RELEASE still does not recognize or does not work on your controller please open a new PR. Note, latest stable/8 and stable/7 supports latest RealTek controllers like RTL8401, RTL8105. Not sure you have this controller though.
 
OK, I have some new information on this issue, although again it doesn't seem to be very helpful...
I tried DragonflyBSD CD just to see how it would handle the re0 device and you know, it works fine with their if_re driver version.

Sure, the code is different in many places (although originally derived from the same source), especially so in using additional system headers which are not found on FreeBSD system.
 
MellowCat, thank you for the info. But unfortunately upgrade to STABLE didn't help.

Code:
$ uname -a
FreeBSD freebsd.gabell.net 8.2-STABLE FreeBSD 8.2-STABLE #1: Tue Jun  7 22:03:50 MSD 2011    
 root@freebsd.gabell.net:/usr/obj/usr/src/sys/MYKERNEL  i386
Code:
$dmesg
re0: <RealTek 8168/8111 B/C/CP/D/DP/E PCIe Gigabit Ethernet> port 0xd800-0xd8ff mem 0xdf6ff000-0xdf6fffff irq 17 at device 0.0 on pci2
re0: Using 1 MSI message
re0: Chip rev. 0x38000000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX,
 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
re0: Ethernet address: 00:1a:92:f0:c1:53
re0: [ITHREAD]
re0: link state changed to DOWN
I've posted pr.
Could somebody check it. It's without reply more then 10 days. Did I do something wrong (It's my first experience :r)?
 
MellowCat said:
I've already responded to same issue on

http://forums.freebsd.org:8080/showthread.php?t=22664

The re(4) driver in 8.2-RELEASE is broken for RealTek 8169/8111, and is fixed if you use 8.2-STABLE (I used STABLE snapshot from May 2011).

Either that or just check out the re source from STABLE and replace your existing driver on RELEASE.

MellowCat, could you point to some info on how to check out the re source and replace the driver in RELEASE? I would like to avoid moving to STABLE branch...
 
Well, as the topic starter I can report that for me it was solved when I moved away from that motherboard where the NIC in question was installed. The motherboard started giving me other problems, including the HDD controller not always recognizing the connected drives.

The last release I tried was RELEASE-9.0 (when it was the latest one there) and though the boot message implied this time that the interface was UP, DHCP still couldn't work. And now I can't continue with this thread for the reasons mentioned above.
 
free-and-bsd said:
The last release I tried was RELEASE-9.0 (when it was the latest one there) and though the boot message implied this time that the interface was UP, DHCP still couldn't work. And now I can't continue with this thread for the reasons mentioned above.
I've had that with a recent board and re(4) too. FreeBSD 9.1-RELEASE would recognise the card but it never worked. Not a single bit came out the interface. Upgrading to 9-STABLE solved it for me. Which was slightly problematic as I had to install a known working network card to be able to upgrade.
 
Back
Top