# WOL and Realtek 8168F based NIC



## fleon (Feb 22, 2013)

First off, I'm using FreeBSD 9.0 here - it pre-dates 8168F support, although the card seemed to work fine on the standard driver in all respects except WOL. I'm aware, however, that support for this chip only appeared in 9.1 and 8.3.

What I've done is get hold of the latest if_re.c (Rev 1.229, Dec 4 2012) and the pci.h and other headers with the symbolic constants it uses for defining the registers etc, and compiled a new if_re.ko using the Makefile in src/sys/modules. I've then copied this in to /boot/kernel. All seems fine (nothing broke), except WOL still doesn't work.

I made up the procedure above, because I couldn't find any documentation on how to do this. Is copying the .ko file enough, or am I being wildly optimistic and the real driver is compiled in to the kernel or something (in which case why put a .ko in there to fool me?)

Before anyone asks, I know I'm doing WOL properly because if I put a NIC with an 8158B in exactly the same slot it works just fine.

A link to the appropriate FM for me to read would be useful, if nothing else. Thanks!


----------



## cpm@ (Feb 22, 2013)

Please, read this helpful thread about WOL using controller RTL8168E PCIe Gigabit ethernet.


----------



## fleon (Feb 24, 2013)

cpu82 said:
			
		

> Please, read this helpful thread about WOL using controller RTL8168E PCIe Gigabit ethernet.



Thanks. I'd already read that, which is why I compiled  the very latest drivers. The fix was incorporated in 9.1 and 8.3 anyway (and I'd already checked the source code against the patch, just to be sure).

As I think I mentioned, I've isolated it to the 8168F - pull it out and put a 8168B in to the same PCIe slot and everything just works, with both old and new if_re.ko.

I did think of tagging this on to that thread, but it's a different chip AND the patch didn't work (nor did the latest drivers).

My main worry is that I'm not actually installing the driver correctly (i.e. it's not being used) - if anyone can confirm or deny this, it'd eliminate one line of enquiry for me. After which I'll proceed with hacking the driver properly!

Thanks, Frank.


----------



## Uniballer (Feb 24, 2013)

You don't say if you are using the GENERIC kernel, but it definitely has the if_re code included.
If you just build and install a complete kernel then you won't need to wonder...

For that matter, why not run 9.1?


----------



## fleon (Feb 24, 2013)

I was going to test it out with 9.1, but I really want this to work everything. There are plenty of other solutions to get around the problem - a network PDU for a start - I'm just trying to get to the bottom of the issue.

As I'm using a compiled driver later than the 9.1 version, I doubt using 9.1 would help.

(Not that it matters to the problem, but this all started by trying to get WOL working on Broadcomm chips).

Now what you say about using the GENERIC kernel is really interesting. Yes I am. I think. Okay:


```
uname -v
FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:46:30 UTC 2012     [email]root@farrell.cse.buffalo.edu[/email]:/usr/obj/usr/src/sys/GENERIC
```

I take it this means I am, but I'm not 100% sure.

This is where my knowledge of FreeBSD gets a bit hazy (and hence the question). I suspected that the driver actually used may be compiled in to the kernel, but if this was the case, why is /boot/kernel/if_re.ko there? You're implying that this is ignored (which is what I suspected). Correct? If so, is there an easy way of making the system NOT ignore it, but use it instead of the compiled-in version. This is not at all like what I'm really used to (System V).

Thanks, Frank.


----------



## fleon (Feb 24, 2013)

Okay - I'm digging around in the kernel config and building one that doesn't include if_re, on the assumption that the one in /boot/kernel was a red herring all along. I'm now assuming I can load it at manually a boot time from if_re.ko, and this is a sensible way to experiment with it. Reasonable?


----------



## wblock@ (Feb 24, 2013)

Building a kernel builds both the monolithic kernel defined in the kernel config file, and the separate loadable kernel modules.  If a module is included in the kernel config, it is built into the kernel.  Separate modules can be loaded at runtime.  Trying to load a module that is already part of the kernel gives an error.


----------



## fleon (Feb 24, 2013)

*Solved!*

It turned out that the driver in /boot/kernel/if_re.ko was completely ignored, which explained why I couldn't get WOL to work. This might seem obvious if you've been around this part of FreeBSD before, but it was new to me.

For anyone else trying to do a similar thing: what I did was download the latest if_re.c from freebsd.org and compile it. To do this, the source file goes here:

/usr/src/sys/dev/re

But you can't just go to the directory and type "make" - to do that go to:

/usr/src/sys/modules/re

and type "make". It took me a while to figure that one out.

You'll get a lot of compiler errors about missing constants, as you need to update some header files - figure out what they are and download them too. Assuming you know about 'C' it shouldn't be a problem; if you don't then I can't explain it in a BB post.

You'll end up with a new if_re.ko in the working directory. Copy this to /boot/kernel on top of the old one. (Hint: you might want to make a backup).

Next you need to persuade the kernel to load the external .ko module. Just 'cos it's there, doesn't mean it's used. To do this create a new kernel configuration, commenting out the Ethernet adapter line device re, and rebuild and install the kernel (as per the Handbook).

Then in /boot/loader.conf add add the following line:


```
if_re_load="yes"
```

Either that, or load the driver manually using kldload(8).

You could, of course, compile the new driver in to the old kernel but I wanted to keep it separate while I tweaked it.

What I don't know yet is whether loading the external module with the compiled-in one still present would work/not work or mess things up spectacularly. I'll try that another time.

Thanks for all the suggestions folks! Frank.


----------

