Intel ATOM D945GCLF onboard LAN driver-card problem
-
none1@pci1:0:0: class=0x020000 card=0x00018086 chip=0x813610ec rev=0x02 hdr=0x00
vendor = 'Realtek Semiconductor'
device = 'RTL8139/810x Family Fast Ethernet NIC'
class = network
subclass = ethernetThat's the device we're trying to support.
The Intel vendor ID always amuses me - note that the low word of 'card', the subvendor ID, is 0x8086.
'Chip' is the more important value - the low word is 0x10ec, which is Realtek. The high word is 0x8136 - Realtek 8101E alike. The re(4) driver already has support for the Realtek 8101E.
Looking at if_re.c, I can only surmise that the driver is trying to attach to this NIC expecting a Realtek 8101E, but discovers that it's a different hardware revision to one it expects for the 8101E, so it doesn't attach to the chip. After all, 8102E is not 8101E! Hopefully someone can get hold of the necessary programming documentation to add support for the NIC that is on this Intel board.
I have had a quick glance at the Linux driver, but it didn't help me understand what was happening. I'm not familiar with Linux drivers, and the driver API is somewhat different to FreeBSD.
-
David_W thank you for your reply.
I tried installing Freebsd 7.0 but no luck…
I also searched on Google and I find that a lot of people have problem with this onboard LAN.. but I am new in Freebsd so I can do much to help them... so I must be patient and wait... hopefully this will be resolved quickly.
If I can do something to help....
Regards
-
Any news on this subject?
-
As others have said, the driver needs to be in FreeBSD before you'll get anywhere. You may find that you need to raise this on the freebsd-net mailing list (and if you really want it to work, you may have to donate a working card/motherboard to a developer).
One thing to keep in mind, new drivers tend to appear in HEAD, which is 8.0. Some may be back-ported to 7.x but few are likely to be back-ported to 6.x.
-
The problem is in network card RTL8102E. I downloaded freebsd drivers from http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=14&PFid=7&Level=5&Conn=4&DownTypeID=3&GetDown=false
instaled freebsd 6.2 , compiled if_rl.ko driver, put it /boot/kernel/if_rl.ko and in /boot/defaults/loader.conf change if_rl_load="NO" to "YES"
my dmesg:
rl0: <realtek rtl810xe="" pci-e="" fast="" ethernet="" adapter="">port 0x2000-0x20ff mem 0x50200000-0x50200fff,0x50000000-0x5000ffff irq 11 at device 0.0 on pci1
rl0: [GIANT-LOCKED]
version:1.76 beta1</realtek> -
Does that mean this is working now?
-
In a word - no.
Unfortunately Realtek's driver is forked from an ancient version of if_rl.c - by ancient I mean six years old and on the FreeBSD 4.x branch. There's no straightforward way of porting their changes back to FreeBSD HEAD, 7-STABLE and 6-STABLE, which is the only way these changes are going to make it into FreeBSD proper.
Maybe Realtek have taken objection to the comment in the driver that the 8139 is possibly the worst PCI Ethernet NIC ever made (with one exception). Their version has deleted that comment. To see what I mean, look here, fairly near the top.
Realtek's code updates the PIO based rl(4) driver, not the DMA based re(4) driver, which is where you really want support. Further, the dmesg extract mindziux posted shows that Realtek's driver is under the Giant lock. Both these will hurt performance badly.
Networking drivers that need the Giant lock will not be committed to FreeBSD HEAD; a process is underway at the moment to get the remaining networking drivers out from under the Giant lock. Those drivers that do not get updated will be deleted. See recent posts by Robert Watson to freebsd-stable for more details.
It would have been so much better if Realtek worked with the FreeBSD developers to get their patches incorporated into the operating system, as other vendors do (including Broadcom and Intel for network drivers, and LSI Logic for storage drivers). The ancient code base of their driver means it's reaching the end of the line, as the networking code in 7.x and HEAD is very different to the 4.x base of Realtek's driver.
If you are desperate to get things working, follow mindzuix's steps, but the performance will be suspect at best. I would suggest not using this NIC at all - use an Intel Gigabit NIC in the PCI slot. It's a huge shame that Intel used this cheap Realtek NIC rather than one of their own NICs on this board; the Realtek NIC is just about OK as a desktop NIC, but I believe is a poor choice for a server or firewall NIC.
-
Hi to all the Atom fan's here who are struggling with their RTL8101E (or is it a RTL8102E) nic.
I received my D945GCLF last week but it wasn't until last weekend that I got to play with it. Unfortunately the amount of play regarding the network capabilities was small. The problems described in the posting before me have plagued me too. Other linux distro's, I have tried SuSe, Ubuntu, Knoppix on the board result in the same non responsive NIC.
lspci -v -n on a SuSe install tells me:
01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet controller [10ec:8136] (rev 02)
Subsystem: Intel Corporation Device [8086:0001]
Flags: bus master, fast devsel, latency 0, IRQ 220
I/O ports at 2000 Memory at 88200000 (64-bit, non-prefetchable)
Memory at 88000000 (64-bit, prefetchable)
Expansion ROM at 88020000 [disabled]
Capabilities: [40] Power Management version 3
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [ac] MSI-X: Enable- Mask- TabSize=2
Capabilities: [cc] Vital Product Data
Kernel driver in use: r8169
Kernel modules: r8169It seems SuSe loads another kernel module, with mixed results. 8 out of 10 reboots the nic stay dead. Switching from manual IP to dhcp only results in the dhcp request being backgrounded (and eventually resulting in no IP being received). Not that superb if you'r thinking of using the Atom board as a router/home server. Unfortunately I had to reinstate my old Epia M10K as a router and stuck an Intel 1000GT in the one PCI Slot on the D945GCLF. After that the RTL nic get's properly activated as well (receives an IP through dhcp) and is willing to work. If I removed the Intel nic, I am back at the lottery.
I have emailed RealTek about the problems but so far little good advise (.. update linux driver) or maintaining a dual boot with XP and enable WOL from the windows driver (not an option for a linux only server).
Even though the replies have been rather gloomy I do hope for a driver update with normal support for the 8101/2E so I can eclaim the Gbit nic from the Atom box.
-
Pantagruel, as others have said, many times and in this thread, pfSense is based on FreeBSD, FreeBSD is not Linux. Getting it working under Linux doesn't really help.
Nice to know that it's as broken under Linux as FreeBSD though ;)
-
@Cry:
.. FreeBSD is not Linux. Getting it working under Linux doesn't really help.
Nice to know that it's as broken under Linux as FreeBSD though ;)
I know but it's a small step from a solution regarding freebsd to solving it for linux (or vice versa)
-
Sounds like we're just going to have to wait for intel to update this board or use PCI. I was disapointed it wasn't gigabit anyway but it still would have been nice to use as a wan port.
-
RealTek mailed me about changing/upgrading the driver.
Drivers can be found at:
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=2&PNid=14&PFid=7&Level=5&Conn=4&DownTypeID=3&GetDown=false
Perhaps this will be of any help to you as well. I'll go and wreck my install later this evening.
-
RealTek mailed me about changing/upgrading the driver.
I've already dealt with this; I spent quite a bit of time investigating the situation a few days ago.
There's almost zero, nothing, zilch, nada in common between the Linux and FreeBSD drivers, Pantagruel - it's not a small step for solving the problem on one kernel to solving it on another when there's no common code. Sometimes code reading the drivers for Linux helps when writing FreeBSD drivers, especially if you're after a small tweak to support a new variant of a device on FreeBSD that is already supported on Linux.
In this case, I can't see anything in the Linux kernel that will help in supporting this NIC in the FreeBSD re(4) driver. I'm not an expert on FreeBSD device drivers, but I am pretty familiar with FreeBSD in general and I am a competent C programmer. If you've got at least some familiarity with C, by all means compare the if_re.c file in FreeBSD (in src/sys/dev/re) with the Realtek driver in the Linux kernel.
Realtek's driver for FreeBSD apparently works, but it's utterly horrible. It's based on 6 year old FreeBSD code which is PIO based (so no DMA, which means horrible I/O performance) and is under the Giant lock (so no threading - not that this is a surprise for code based on the non-SMP FreeBSD 4.x). Because of the ancient revision Realtek have forked from, it would be very hard to backport the changes to a modern version of the rl(4) driver, let alone the re(4) driver, which is where you want support.
Realtek could have chosen to work with the FreeBSD developers on getting their hardware supported properly - other companies such as Intel, Broadcom and LSI Logic have done so.
I expect that the built in NIC on the Atom board will be supported eventually - there's likely to be a lot of these boards, so someone is going to be interested in doing the work. Finding an interested FreeBSD developer and offering them hardware or money is likely to get this work done sooner, though it still relies on finding (or obtaining) programming details from Realtek. The datasheets that are publicly available don't have the programming details necessary.
Even if you did get the built in NIC working, Realtek NICs are far from brilliant - search the forum for Realtek for the issues that people are experiencing. It's a cheap 10/100 desktop NIC. For a firewall, I'd put an Intel Gigabit NIC in the PCI slot and have done - even a cheap Intel Gigabit desktop NIC would be very much better than this Realtek device.
I think there's only single port desktop NICs, but if you have a switch that supports VLANs (which work fine with the single port Intel 1000/GT PCI desktop adapter), you only need a single NIC for pfSense.
-
There's some work going on to support this card now - see the posts of the last few days in freebsd-stable (the thread starts here (click)). Basic support has been managed, but doesn't appear to be in a state to be committed yet. The more complex features of the chip are proving more troublesome, because the 8102E is different to the 8101E.
Hopefully this will turn into something that gets committed to FreeBSD HEAD, then MFCed to 7-STABLE. I'm not so sure any patch will be made to 6-STABLE, but now that pfSense 1.2.1 looks as if it will be based around FreeBSD 7, hopefully that won't be an issue.
-
There appears to be a tweak in HEAD related to this device as of half a day ago.
http://freshbsd.org/2008/07/09/01/58/18
No code changes, just PCI device IDs as far as I can see, so I'm not sure how much it will actually affect.
-
Hi
I just got one of these great boards also. Any news on how to add support for the nic ?
Thanks! :)
-
Hi,
I have one myself too, but just bought cheap and put PCI a D-Link's Intel-base 4 ports card.
cheers,
-
none1@pci1:0:0: class=0x020000 card=0x00018086 chip=0x813610ec rev=0x02 hdr=0x00
vendor = 'Realtek Semiconductor'
device = 'RTL8139/810x Family Fast Ethernet NIC'
class = network
subclass = ethernetThat's the device we're trying to support.
The Intel vendor ID always amuses me - note that the low word of 'card', the subvendor ID, is 0x8086.
'Chip' is the more important value - the low word is 0x10ec, which is Realtek. The high word is 0x8136 - Realtek 8101E alike. The re(4) driver already has support for the Realtek 8101E.
Looking at if_re.c, I can only surmise that the driver is trying to attach to this NIC expecting a Realtek 8101E, but discovers that it's a different hardware revision to one it expects for the 8101E, so it doesn't attach to the chip. After all, 8102E is not 8101E! Hopefully someone can get hold of the necessary programming documentation to add support for the NIC that is on this Intel board.
I have had a quick glance at the Linux driver, but it didn't help me understand what was happening. I'm not familiar with Linux drivers, and the driver API is somewhat different to FreeBSD.
I have also a card like this.
I have modified /usr/src/sys/pci/if_rl.c in the 'static struc rl_type rl_devs[] ='
I have added the following lines :
{ RT_VENDORID, RT_DEVICEID_8101E, RL_8139,
"Realtek 8102E 10/100BaseTX" },After compilation this seems to work (card is correctly detected, with right Mac Address), but phy that is detected is 100BaseT4 and no carrier is found.
I think there is some fix to add somewhere and I still investigate where I can fix that….
To be continued...
[…Some update...]
Okay after looking inside CVSweb, and haxoring a bit FreeBSD i was being able to compile this on FreeBSD :You will need from CVS :
src/sys/sys/sockio.h
src/pci/if_rlreg.h
src/sys/net/if.h
src/sys/net/if.c
src/sys/dev/re/if_re.cFrom RELENG_7 Branch (this can be also backported form RELENG_6 as well, thus not tested yet. I don't have any FreeBSD 6 on my hand with this mobo).
On if_re.c, you will have to modify the line 2235 :
m_new = m_collapse(*m_head, M_DONTWAIT, RL_NTXSEGS);
by
m_new = m_defrag(*m_head, M_DONTWAIT);
And you will have an brand new interface with support of this card :
re0: <realtek 10="" 8101e="" 8102e="" 8102el="" pcie="" 100basetx="">port 0x2000-0x20ff mem 0x88200000-0x88200fff,0x88000000-0x8800ffff irq 16 at device 0.0 on pci1
re0: turning off MSI enable bit.
re0: Chip rev. 0x24800000
re0: MAC rev. 0x00200000
miibus0: <mii bus="">on re0
rlphy0: <rtl8201l 10="" 100="" media="" interface="">PHY 1 on miibus0
rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re0: Ethernet address: 00:1c:c0:45:21:04
re0: [FILTER]</rtl8201l></mii></realtek> -
Good morning,
Realtek released a new driver - Version 1.77 - release Date 2008/10/27. Seems to be new. Does anybody tried this driver?
At the moment I switched back to my Intel Celeron DLG201 Board, but the atom would be more interesting. -
FYI: I just installed pfsense 1.2.1 rc2 from nov 17 on intel atom. It recognized the 8102EL just fine…