# can't build realtek r1000 module (Solved)

## paulisdead

I'm trying to get my onboard realtek gigE nic to on my gigabyte P35 mobo work and I can't get the r1000 module to build.  lspci shows it as Ethernet controller: Realtek Semiconductor Co., Ltd. Unknown device 8168 (rev 01).  This is the last thing I gotta get working to have a 100% working system with this brand new spanking mobo, which is still quite amazing considering how new this mobo is, and how well it's working on Gentoo.  The kernel 8169/8168 driver doesn't pick up the NIC, and when I do "make clean modules I get this

 *Quote:*   

> deepthought r1000_v1.06 # make clean modules
> 
> make -C src/ clean
> 
> make[1]: Entering directory `/usr/src/r1000_v1.06/src'
> ...

 

I've tried setting my kernel hz to 250 and 1000, and neither worked.  I've been using the 2.6.22-rc4 and rc5 kernels since I figured they'd work best on the really new hardware.

----------

## didymos

 *Quote:*   

> 
> 
> make -f Makefile_linux24x 
> 
> 

 

There's a problem.  Seems the drivers are intended for a 2.4 kernel, and a check of opendrivers.com confirms that:

 *Quote:*   

> 
> 
> Realtek RTL8100E/8101E PCI-E Series Driver 1.06 Linux Kernel 2.4.x (Support x86 and x64).
> 
> FileName:r1000_v1.06.tgz
> ...

 

What was the kernel driver you selected called?  Also, you realize that the 2.6.22 series is unstable at the moment, right?

----------

## mbar

I also have Gigabyte mainboard with P35 chipset and exactly the same Realtek nic and it works OK with in-kernel Realtek driver (kernel 2.6.21). Please post your dmesg.

----------

## didymos

Nevermind about the driver name.  Found that.  Did you build it as a module or go with it being built into the kernel?

----------

## paulisdead

When I modprobe r8169, I get absolutely nothing in dmesg.  I found the driver that's supposed to be for 2.6 but that one won't build either

```
deepthought r8168-8.001.00 # make clean modules

make -C src/ clean

make[1]: Entering directory `/usr/src/r8168-8.001.00/src'

rm -rf *.o *.ko *~ core* .dep* .*.d .*.cmd *.mod.c *.a *.s .*.flags .tmp_versions

make[1]: Leaving directory `/usr/src/r8168-8.001.00/src'

make -C src/ modules

make[1]: Entering directory `/usr/src/r8168-8.001.00/src'

make -C /lib/modules/2.6.22-rc5/build SUBDIRS=/usr/src/r8168-8.001.00/src modules

make[2]: Entering directory `/usr/src/linux-2.6.22-rc5'

  CC [M]  /usr/src/r8168-8.001.00/src/r8168_n.o

/usr/src/r8168-8.001.00/src/r8168_n.c: In function 'rtl8168_tso_csum':

/usr/src/r8168-8.001.00/src/r8168_n.c:2424: error: 'struct sk_buff' has no member named 'nh'

/usr/src/r8168-8.001.00/src/r8168_n.c: In function 'rtl8168_init_module':

/usr/src/r8168-8.001.00/src/r8168_n.c:3123: warning: implicit declaration of function 'pci_module_init'

make[3]: *** [/usr/src/r8168-8.001.00/src/r8168_n.o] Error 1

make[2]: *** [_module_/usr/src/r8168-8.001.00/src] Error 2

make[2]: Leaving directory `/usr/src/linux-2.6.22-rc5'

make[1]: *** [modules] Error 2

make[1]: Leaving directory `/usr/src/r8168-8.001.00/src'

make: *** [modules] Error 2
```

----------

## didymos

Yeah, it's probably not aware of the changes in 2.6.22, since that's the unstable branch.  Have you tried using a 2.6.21 kernel?  The other option is to patch the driver so it works with 2.6.22.  Well, compiles.  No guarantee it'd work even if it built successfully.  By the way, if you haven't changed the source or configuration, you don't need to run "make clean" every time.

----------

## paulisdead

I got it figured out with r8168, it was a combination of windows disabling the NIC when being turned off, and the fact that it's getting picked up as eth15.  Even when I took out the PCI NIC I've been using it still picks up as eth15 for some strange reason.  There's only the one onboard NIC in there now, so one would think it would be eth0.  I hadn't thought of windows disabling the NIC since I wasn't able to get it to work even before I installed windows, but I guess I was just looking in the wrong place for it as eth0.

If anyone has any explanation for why it's eth15, or any idea how to get it back to eth0 I'd like to hear it.

I'm getting a little bit of odd behavior from the NIC too.  Transfers are great and I'm not even using jumbo frames, but dragging mp3/oggs into xmms is taking a long awhile.  Worked perfectly fine on the intel pro100 I was using not even an hour ago.  I'm using NFS to access my music and videos on my home fileserver and just copying over a large file the transfers were between 20-50MB/s.  Maybe it's finally time to look for another audio player...

*edit*  I saw a ton of hda drive not ready errors in dmesg that weren't there last time I looked.  Disabled all the onboard jmicron stuff in the bios and xmms started working fine.  No idea if it's the jmicron controller or the dvd burner, I'll have to look into it.  Now I'm pretty happy with this NIC, just wondering why it's eth15.

----------

## mbar

 *paulisdead wrote:*   

> windows disabling the NIC when being turned off

 

To avoid that just enable Wake-On-Lan After Shtdown feature in Realtek properties in Device Manager. It prevents Windows from shutting down NIC interface, because WOL needs NIC's phy transmitter/receiver to be powered (enabled).

----------

## paulisdead

 *mbar wrote:*   

>  *paulisdead wrote:*   windows disabling the NIC when being turned off 
> 
> To avoid that just enable Wake-On-Lan After Shtdown feature in Realtek properties in Device Manager. It prevents Windows from shutting down NIC interface, because WOL needs NIC's phy transmitter/receiver to be powered (enabled).

 

Yup I figured that out, just still curious why it's eth15.  Not a big deal, since it's working fantastic right now.  Just ordered a SATA DVD burner so I won't have to deal with the jmicron controller as well, though I don't know if it's the drive or controller causing the problems, either way it should solve my issues.

----------

## didymos

Delete /etc/udev/rules.d/70-persistent-net.rules and reboot.  Should go back to being eth0.

----------

## paulisdead

 *didymos wrote:*   

> Delete /etc/udev/rules.d/70-persistent-net.rules and reboot.  Should go back to being eth0.

 

Awesome, that did the trick, thanks man.

----------

## okel

Hello paulisdead,

when I get that right, you had a compilation problem with both, 2.4 and 2.6 versions of the driver with a 2.6.22 kernel. How did you solve that problem?

Okel

----------

## paulisdead

 *okel wrote:*   

> Hello paulisdead,
> 
> when I get that right, you had a compilation problem with both, 2.4 and 2.6 versions of the driver with a 2.6.22 kernel. How did you solve that problem?
> 
> Okel

 

I didn't, I used the r8168 module that comes with the kernel, but since my install's like 3-4 years old I have some stail files, so I had to delete a udev file I listed above to get this NIC to show up as eth0 instead of eth15.  It wasn't until I did en ifconfig -a, that I realized it was being misdetected as eth15.

----------

## okel

Unfortunately, there were no r8168 drivers in the kernel. I tried the r8169 drivers with a 2.6.21 kernel but failed. I suspect, they changed, because with the 2.6.22-r2 the r8169 drivers work well. Thank you.

Stefan

----------

## paulisdead

 *okel wrote:*   

> Unfortunately, there were no r8168 drivers in the kernel. I tried the r8169 drivers with a 2.6.21 kernel but failed. I suspect, they changed, because with the 2.6.22-r2 the r8169 drivers work well. Thank you.
> 
> Stefan

 

oh that's right they are called r8169, sorry sometimes it gets easy to confuse all the numbers and acronyms that get thrown around.

----------

