Wake-on-lan broken for some Realtek NIC's


Recommended Posts

If this RTL8111E not going to be supported, is the a good one?

 

http://www.intel.com/content/www/us/en/network-adapters/gigabit-network-adapters/gigabit-ct-desktop-adapter.html

 

Cost about 34Euros, but since it have been OK prevues I don't like to spend money on a new one.

 

//Peter

Do some searching on google about wake on lan and this NIC on Linux systems.  Generally speaking WOL and Intel NICs tend to work pretty well (morso than Realtek ones)

Link to comment

Realtek should be unsupported on UnRAID. This is damaging UnRAID development cycle to continue further.

 

Even ESXi don't recommend Realtek.

That is taking it a little far.  The Realtek NIC works fine, save for what appears to be an issue with WOL.

Link to comment
Even ESXi don't recommend Realtek.

 

I first became wary of Realtek NIC chipsets back in the early 1990s.  Nothing that I've seen or heard since then has made me feel any more comfortable with them.  It's a great shame that they are used in the majority of motherboards.

Link to comment

Even ESXi don't recommend Realtek.

 

I first became wary of Realtek NIC chipsets back in the early 1990s.  Nothing that I've seen or heard since then has made me feel any more comfortable with them.  It's a great shame that they are used in the majority of motherboards.

 

It is a shame, Realtek NIC licence is dead cheap and it work perfect on Windows.. that is my most motherboard companies go with Realtek NIC

Link to comment

I first became wary of Realtek NIC chipsets back in the early 1990s.  Nothing that I've seen or heard since then has made me feel any more comfortable with them.  It's a great shame that they are used in the majority of motherboards.

 

It is a shame, Realtek NIC licence is dead cheap and it work perfect on Windows.. that is my most motherboard companies go with Realtek NIC

 

My experience, 20 years ago, was in a Microsoft environment.

Link to comment

To someone seeing this issue: please post your system log, I want to make sure the NIC firmware is being loaded.

 

Many Realtek NIC's require "firmware" to be loaded into the NIC at start-up time.  This firmware is not released under any kind of license that lets it be distributed with the linux kernel, so someone wanting to compile a kernel has to manually hunt down the firmware and download it themselves (which I do, and yes all the firmware is up-to-date AFAIK).  Yes this is a PITA.

http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/rtl_nic

 

I want to see if those seeing this issue have any syslog messages warning about "missing firmware".

Link to comment

I manage to compile r8168 on the kernel for RC13, and used the below command in my go file to switch to the r8168, but no success of waking up the server, it looked OK in the syslog before I put the server in sleep mode.

 

EDIT

 

The WOL are working !

Link to comment

I manage to compile r8168 on the kernel for RC13, and used the below command in my go file to switch to the r8168, but no success of waking up the server, it looked OK in the syslog before I put the server in sleep mode.

 

 

 

 Replace Realtek r8169 driver to r8168
cd /lib/modules/2.6.32.9-unRAID/kernel/drivers/net
rmmod r8169
mv r8169.ko r8169.ko.bak
cp /boot/packagescustom/r8168.ko .
depmod -a
insmod r8168.ko/code]

 

The -rc13 kernel is not 2.6.32.9, it's 3.9.3.  Assuming above is a typo, did you edit something in the Realtek source to get to compile?

Link to comment

I manage to compile r8168 on the kernel for RC13, and used the below command in my go file to switch to the r8168, but no success of waking up the server, it looked OK in the syslog before I put the server in sleep mode.

 

 

 

The -rc13 kernel is not 2.6.32.9, it's 3.9.3.  Assuming above is a typo, did you edit something in the Realtek source to get to compile?

 

Yes, I applied a patch , then it was OK to compile, this is the patch r8168-8.035.00.patch more info here -> https://code.google.com/p/r8168/issues/detail?id=12

 

I also needed to modify on file

 

The file "rtlool.c" needs an extra line ("#include <linux/capability.h>") at the top:

 

sed -i '1i #include <linux/capability.h>' /mnt/disk1/workdir/r8168-8.029.00/src/rtltool.c

 

 

 

And WOL are OK with this "unRaid patch" 8)

 

EDIT

 

 

The link to my r8168 file -> https://dl.dropboxusercontent.com/u/46562247/r8168.ko

//Peter

Link to comment

There's a driver available on the Realtek site called r8168-8.036.00 (but not on that googlecode page) that does compile ok with 3.9.6.

rc15a anyone? (you might want to get someone with that chipset to try before posting rc15 for everyone else.  I can give it a try here with my SuperMicro C2SEE MB if you wish.  I'll be around all weekend when not doing yard-work, errands, etc. )

 

However, just a warning...  It has never woken from S3 sleep.    No issue, since I don't ever put the server to sleep, except as a test.

Link to comment

There's a driver available on the Realtek site called r8168-8.036.00 (but not on that googlecode page) that does compile ok with 3.9.6.

rc15a anyone? (you might want to get someone with that chipset to try before posting rc15 for everyone else.  I can give it a try here with my SuperMicro C2SEE MB if you wish.  I'll be around all weekend when not doing yard-work, errands, etc. )

 

However, just a warning...  It has never woken from S3 sleep.    No issue, since I don't ever put the server to sleep, except as a test.

 

Release -rc15 will include Realtek's "r8168" driver (like is in -rc12a and -rc14) instead of linux stock "r8168" driver (which was in -rc13).  The only thing from stopping me using stock driver are reports that WOL doesn't work.

 

Here is a brief history of linux realtek ethernet drivers as best as I can cobble together:

 

In the beginning the first Realtek GigEthernet driver was produced by Realtek and supported their PCI-based Gig chips.  They called this driver "r8169".

 

Sometime after, someone in linux kernel development said, "great, let's put this in the kernel source tree".  They called this driver also "r8169".

 

From that point on the two drivers diverged in terms of chips supported, features, bug fixes.

 

Eventually Realtek came out with some PCI-Express NIC chips.  For these devices, Realtek provided a new driver.  They called this "r8168" (just to confuse people, which they have accomplished).

 

Well the linux guys, seeing this "new" driver, and realizing Realtek just took their old driver and modified it for the new chips, decided, "hell let's just put Realtek's changes in our r8169 driver", so they did (just to confuse people, which they have accomplished).

 

We're left with this situation:

Realtek r8169 - supports PCI-based gig chips

Realtek r8168 - supports PCI-E based gig chips

linux r8169 - supports both PCI-based gig chips and PCI-E based gig chips

 

The real action these days is in the Realtek r8168 and linux r8169 drivers.  You see people on various linux forums substituting one for the other depending on which is working better at that time.

 

What's this mean for unRaid?

I either include the stock linux r8169 driver, OR

I include both the Realtek r8169 and r8168 drivers.

 

As of this post, only the Realtek r8168 driver compiles as-is with 3.9.x kenel, but I was able to make Realtek r8169 driver compile with a couple minor edits.

 

So -rc15 will be released with Realtek drivers.

 

Make sense?

Link to comment
  • 2 weeks later...

I know that Realtek is a PITA with this, but seeing as they seem to be on a lot of consumer motherboards I'm of the opinion that it's a pill that has to be swallowed (also, I've got a Realtek on my board and am looking into WOL...).

 

When I built my unRAID box, I wanted as much as possible on the MB as I could get (lots of SATA ports, on-board gigabit NIC, VGA).  Why not, after all?  It was sold to me as a fairly cheap and expandable NAS solution that could make use of existing drives, etc. (and that's still what I recommend it as to colleagues and friends).  If people want to run server-grade gear, they might have a different solution, and not everybody wants to go searching out and paying for additional cards.

 

As much as I really do value the forum and Wiki, the simpler everything is for the end user, the better.  "It just works" is a huge bonus with people who's lives don't want to be cluttered with the finer points of a NAS drive.

 

If a reliable WOL is an option to an all ready great solution, then go for it.

 

Apologies, I know that this does not add to the Issue solution, but I felt compelled to comment after it was suggested that a large portion of network interfaces should be chopped out.  Feel free to remove if I'm out of line or I've misunderstood.

Link to comment