DebianThis forum is for the discussion of Debian Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I must have the worst luck with onboard Nic's possible. Apparently even the testing version of Debian 3.1 doesn't see the Realtek 8111B 10/100/1000 nic built into the Gigabyte GA-945GM-S2 Motherboard I have.
If I understand lspci correctly, the only thing that the kernel isn't recognizing correctly is the eth0. It appears to be seeing the north and south bridge chipsets and controllers.
I went to the realtek site and downloaded the linux drivers for the 8168 RTL8111B chipset. I uncompressed the tarball and checked out the readme, which states
Quote:
<Linux device driver for Realtek Ethernet controllers>
This is the Linux device driver released for RealTek Ethernet controllers, which are listed as following.
1. RTL8169S/SB/SC (Gigabit Ethernet with PCI interface)
2. RTL8168B (Gigabit Ethernet with PCI-Express interface)
3. RTL8101E (Fast Ethernet with PCI-Express interface)
<Requirements>
- kernel source tree (supported versions 2.4.x or 2.6.x)
- compiler/binutils for kernel compilation
<Quick install with proper kernel settings>
Unpack the tarball :
tar vzxf r1000_vX.YZ.tgz
Change to the directory:
cd r1000_vX.YZ
If you are running the target kernel, then you should be
able to do :
make clean modules (as root or with sudo)
make install
depmod -a
<Force Link Status>
1. Force the link status when insert the driver.
If the user is in the path ~/r1000, the link status can be forced to one of the 5 modes as following command.
,where
SPEED_MODE = 1000 for 1000Mbps
= 100 for 100Mbps
= 10 for 10Mbps
DUPLEX_MODE = 0 for half-duplex
= 1 for full-duplex
NWAY_OPTION = 0 for auto-negotiation off
= 1 for auto-negotiation on
For example:
#insmod ./src/r1000.ko speed=100 duplex=0 autoneg=0
will force PHY to operate in 100Mpbs Half-duplex.
2. Force the link status by using ethtool.
a. Insert the driver first.
b. Make sure that ethtool exists in /sbin.
c. Force the link status as the following command.
,where
SPEED_MODE = 1000 for 1000Mbps
= 100 for 100Mbps
= 10 for 10Mbps
DUPLEX_MODE = half for half-duplex
= full for full-duplex
NWAY_OPTION = off for auto-negotiation off
= on for auto-negotiation on
<Advanced feature>
- Supports Jumbo Frame
- Hardware Tx/Rx flow control
I checked to be sure I was running the kernel I wanted to be
Quote:
$ uname -a
Linux mailin-01 2.6.16-2-686-smp #1 SMP Sat Jul 15 22:33:00 UTC 2006 i686 GNU/Linux
and then went to do a make clean modules at which point it spit out the following error
Quote:
$ make clean modules
make -C src/ clean
make[1]: Entering directory `/downloads/r1000_v1.04/src'
rm -f *.o *.ko *~ core* .dep* .*.d .*.cmd *.mod.c *.a *.s .*.flags
make[1]: Leaving directory `/downloads/r1000_v1.04/src'
make -C src/ modules
make[1]: Entering directory `/downloads/r1000_v1.04/src'
make -C /lib/modules/2.6.16-2-686-smp/build SUBDIRS=/downloads/r1000_v1.04/src modules make: Entering an unknown directory
make: *** /lib/modules/2.6.16-2-686-smp/build: No such file or directory. Stop.
make: Leaving an unknown directory
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/downloads/r1000_v1.04/src'
make: *** [modules] Error 2
I checked and indeed the /lib/modules/2.6.16-2-686-smp/build directory doesn't exist but simply creating it doesn't fix the issue either.
Now I'm really baffled. I thought maybe I'd just compile a new kernel from source.. but during make menuconfig I get the following error.
Quote:
scripts/kconfig/mconf.c:91: error: static declaration of ācurrent_menuā follows non-static declaration
scripts/kconfig/lkc.h:63: error: previous declaration of ācurrent_menuā was here
make[1]: *** [scripts/kconfig/mconf.o] Error 1
make: *** [menuconfig] Error 2
I've had no problems compiling a kernel on other systems, and I ran the ver_linux script included with teh source to make sure I had compatible software.
Also you need the kernel header package not the source this will work for building most modules, install the module-assistant package and run m-a prepare it should download and install the proper headers then create the link needed for building.
Also you need the kernel header package not the source this will work for building most modules, install the module-assistant package and run m-a prepare it should download and install the proper headers then create the link needed for building.
I have the module-assistant package and did run m-a prepare. Here is the my /usr/src directory
Try this for the file I modified the one in my 2.6.16 tree to hopefully get the EXTRAVERSION = correctly which is what it would be looking for anyways as the Makefile contents is pretty generic save it with the same permissions as you see with my 2.6.17 one above.
Try this for the file I modified the one in my 2.6.16 tree to hopefully get the EXTRAVERSION = correctly which is what it would be looking for anyways as the Makefile contents is pretty generic save it with the same permissions as you see with my 2.6.17 one above.
This is baffling.. the Makefiles that are in the linux-headers dirs are symlinked all to hell and back.
I cannot put the regular Makefile in the /usr/src/linux-headers-2.6.16-2-686-smp/arch/i386 directory, and if I change the symlink to the /usr/src/linux-headers-2.6.16-2-686-smp/Makefile it throws it into a never ending loop when I do make clean modules
Here is the make file from the 386 in my 2.6.16 tree, boy you have something weird going on here I would almost say that is a bad build of the headers package. I don't have the headers for the 2.6.16 but I get nothing like that when looking at the files from my self built headers in 2.6.17.
Here is the make file from the 386 in my 2.6.16 tree, boy you have something weird going on here I would almost say that is a bad build of the headers package. I don't have the headers for the 2.6.16 but I get nothing like that when looking at the files from my self built headers in 2.6.17.
I agree that something is wrong with that kernel-headers but I've uninstalled and reinstalled it from apt already and still see the same result. Using your -386 it got farther, but now hangs on Makefile.cpu in the /arch/i386/ directory which is another bogus symlink. =(
I agree that something is wrong with that kernel-headers but I've uninstalled and reinstalled it from apt already and still see the same result. Using your -386 it got farther, but now hangs on Makefile.cpu in the /arch/i386/ directory which is another bogus symlink. =(
Well I'd say it almost time to compile your own kernel then you will have a fully configured source tree and not even need headers for building.
Well I'd say it almost time to compile your own kernel then you will have a fully configured source tree and not even need headers for building.
I got so fed up with it I ended up wiping the box clean. Fortunately I hadn't done anything major on that box so it was only an hour or so to get it up and running again. Wish a fresh install and compiling my own kernel I was able to get the onboard nic working despite Realtek's non-intuitive instructions.
I got so fed up with it I ended up wiping the box clean. Fortunately I hadn't done anything major on that box so it was only an hour or so to get it up and running again. Wish a fresh install and compiling my own kernel I was able to get the onboard nic working despite Realtek's non-intuitive instructions.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
