I installed kernel-source as part of the yum update, so I decided to build a kernel. My attempts to make the kernel consistently failed. 'make mrproper' failed with a DocBook problem. 'make oldconfig' completed okay. Next I tried 'make menuconfig' in which I never found the proper gigabit driver. I then yum installed qt-devel so that I could try 'make xconfig'. I finally found what is probably the correct driver with xconfig - the one for the Marvel Yukon chipset - which I marked to be built in. I saved and exited xconfig and then attempted a 'make'. make chugged along for awhile with some warning messages about 'YY_STACK_USED', YY_ALWAYS_INTERACTIVE', YY_NEVER_INTERACTIVE', and 'YY_MAIN' not being defined and then error exited with 'no rule to make target 'init/main.o';'needed by /init/build_in.o'
Not being a makefile guru, I'm not sure how to get the kernel made.
 
If someone can point me at how to fix that, I believe the final build steps are 'make modules-install' and 'make install'.
 
Finally, I apologize for what is probably all error 299 (excessive operator ignorance) on my part.

Take a look at this article.
 
Try;
 
make xconfig
make all
make modules_install
make install

I tried 'make all' and immediately got an error:
make[1] No rule to make target 'init/main.o'; needed by 'init/buildtin.o'. Stop; make: ***[init]error 2.
 
So,.. I did
make clean
make xconfig
make all
I saw the YY_xxx warnings and then right after 'HOSTCC scripts/conmakehash' I again got the errors make[1] and make stated in the first part of the post.
 
Should I try using rpm on a downloaded source tree instead of yum as I have been doing?

Downloaded vanilla 2.6.14.1 source, moved the tree to /usr/src and then attempted a kernel build using the following steps:
make mrproper
make oldconfig
make xconfig
make all
Everything seems to be working okay, mrproper, oldconfig, and xconfig steps worked without any problems. 'make all' is chunking away on my older celeron/coppermine system. Apparently, I needed something more than 'yum install kernel-src' to succeed. Assuming all of this works (including make modules-install and make install, I'll test the kernel.
 
I'm currently running on the yum updated FC-4 kernel (i.e., 2.6.14-1.1653-FC4 built by the original update of everything) with a 100 Mbit pci card. If the kernel being built boots okay, I'll swap back in the gigabit card and if it works with that kernel then I'll try a similar build process with a download of the 1653-FC4 source.
 
This still begs the question, can I automate yum updates with cron and expect to have everything working when I boot a new system?

The vanilla kernel build (2.6.14.1) succeeded. It recognizes a Dlink 100Mbit card (Realtek RTL8139) and sets it up as eth0. I replaced the card with a Dlink Gbit card and rebooted. The (2.6.14.1) kernel does not recognize the gigabit card. The earlier FC4 kernel (1369) does recognize it and eth0 in dmesg declares it as a DGE-530T Gigabit Ethernet Adapter.
 
I'm not entirely sure how to read dmesg, but what I assume are the PCI vendor and subsystem ID's are 0104 -> 0107 in the Realtek case and 0114 -> 0117 in the case of the DGE-530T.
 
Any suggestions or recommendations? At the moment I am running the 2.6.11-1.1369_FC4 kernel with the gigabit card in the system. The system is a samba file server and I prefer the better response with gigabit. Does this older kernel expose me to security issues?

This just goes to show you that the newest is not always the best! It apparently was a known issue in earlier kernels and fixed in the kernel-2.6.13-1.1532_FC4 version. Apparently it is not fixed in the newest?
 
Try installing that kernel and see what happens.
 
Reference

I neeed to plead error 299 here. I can't find the source for kernel-2.6.13-1.1532_FC4. When I go to download.fedora.redhat, the only kernels I see in update are 2.6.12-1_1456_FC4; 2.6.14-1_1637_FC4; and a couple of other 2.6.14 kernel sources. I don't see any 2.6.13nnn kernels. Am I going about this wrong, or,... ?

I downloaded the 2.6.14-1_1637_FC4 source rpm and built a kernel and booted from it. This kernel did NOT find/initialize the DGE-530T (i.e., no eth0 present with this kernel). So,... the 2.6.11-1.1639_FC4 finds and initializes it, but the 2.6,14-1_1637_FC4 and 2.6.14-1_1653_FC4 kernels do not find it. Should I try the 2.6.12-1_1456_FC4 kernel? Other than a couple of answers that are different in make xconfig (which I mainly answered N or M) these kernels are all using the same .config file.

I built the 2.5.12-1_1456_FC4 kernel and booted from it. The DGE-530T works fine with this kernel.

Great! I just finished up[censored] my kernel to the 2.6.14-1.1653 kernel, which worked for me. I needed to yum the kernel and kernel-devel packages. No need to manually build the kernel.
 
I bet the modprobe.conf lacked the correct designation for the interface.

The sk98lin driver is no more the correct one for D-Link DGE-530T gigabit ethernet card, and probably a whole lot of other cards. The new kernel module is skge. You need to remove a line referencing the old driver from /etc/modprobe.conf, and replace it with skge like this:
 
alias eth0 skge
 
Or maybe you could be able to get kudzu to do that for you, but I do not know how.
 
Hope this helps,
Jaakko Hyvätti
http://www.iki.fi/hyvatti/
 

Thank you!
 
Worked a charm.
 
Been fighting this ever since a kernel update in FC4 'broke' it. Even went so far as to replace the NIC.
 
Thanks!

My Linux box is a Dell DHP desktop with a 2.5GHz Intel Celeron processor, manufactured in June, 2005. This box is running Fedora Core 3 (“uname –r” command returns 2.6.9-1.667 as the kernel version). The computer has an Ethernet interface on the motherboard that was working fine, but I needed a second Ethernet interface. From Office Depot I purchased a D-Link 10/100/1000Mbps Gigabit Desktop Adapter, model DGE-530T, which plugs into the PCI bus. When I first plugged it in to the computer and booted, Linux did not initialize it. After much trial-and-error, I believe these are the settings that are needed to get the card working.
 
File /etc/modprobe.conf
In my modprobe.conf file, only the first two lines of the file are relevant to the problem here, so I only show those lines below. The first line was in this file before I edited it. I added the second line. At first, and for a long time, I tried to get eth1 to work by adding a second line similar to the first: “alias eth1 tg3”. I didn’t initially try to use the line as it is now because one of the first posts I found on the web regarding a similar problem said that sk98lin is no longer valid for gigabit Ethernet cards, and I did not have a file called skge, which was touted as being the replacement for sk98lin, but I did have the sk98lin. I determined the presence/absence of these files using the "find" command, "find / -name sk98lin -print", for example.
 
alias eth0 tg3
alias eth1 sk98lin
 
File /etc/sysconfig/network-scripts/ifcfg-eth0
The contents of this file are shown for reference. It is exactly as I found it and describes the eth0 interface.
 
DEVICE=eth0
ONBOOT=yes
TYPE=Ethernet
BOOTPROTO=dhcp
 
File /etc/sysconfig/network-scripts/ifcfg-eth1
I created this file anew (actually I used the "cp" command to copy the ifcfg-eth0 file to this new file name and then edited it), as none by this name existed on my PC. I found the arguments by Googling for BOOTPROTO. It describes the eth1 interface. I sort of made up the IP address. My eth0 port connects to a router that usually assigns an address of 192.168.1.102 to eth0. My eth1 port connects to a development board that will boot from the Linux box. This development board cannot supply an address via DHCP, so eth1 must be assigned a static IP address. In this file I initially used 192.168.1.250 as the static IP address, but the development board could not ping the port. When I changed the address to 192.168.5.250, I could ping and boot from the development board. The broadcast address is the same as shown on my eth0 port (when I issue the ifconfig command on the Linux box). The NETWORK address is the one that my Windows machine (which is connected to the same router) shows as the Default Gateway (when I issue the ipconfig command from a Command Prompt on the Windows machine).
 
DEVICE=eth1
ONBOOT=yes
TYPE=Ethernet
BOOTPROTO=static
IPADDR=192.168.5.250
NETMASK=255.255.255.0
NETWORK=192.168.1.1
BROADCAST=192.268.1.255
 
lspci
The lspci command shows information about the PCI interface. Early on, after I had plugged in the DGE-530T PCI card but before it was working, it showed up in the output of the lspci command. The line below is the part of the output from lspci that applies to this card. Although the lspci command output shown below was obtained after a boot when the card was working, I believe the entry reads exactly as it did before the card started working.
 
04:00.0 Ethernet controller: D-Link System Inc Gigabit Ethernet Adapter (rev 11)
 
dmesg
When I was searching the web for information on getting this card working under Linux, one common suggestion was to examine the output of the dmesg command. This command apparently displays messages logged by the Linux kernel during the boot process. Before the card was working, there was never an entry in this log for eth1. The suggestions to review the output consistently did not suggest how to respond to the messages you might find in this log, or what to do if there were no messages in the log – thanks anyway. Now that the eth1 port is working (which ultimately happened when I added the correct line to the modprobe.conf file, as shown above) there are entries in the log for eth1. So, I suppose one suggestion I could offer is that if there are no messages for your card in the dmesg output, perhaps you are not specifying a valid driver for your card in your modprobe.conf file - just my take on that. Shown below is the output of the dmesg command, piped through the grep command so that only lines containing “eth” are displayed. The connection up/down entries are due to the booting/restarting of the development board connected to eth1, so no worries.
 
[root@localhost ~]# dmesg | grep eth
divert: not allocating divert_blk for non-ethernet device lo
divert: allocating divert_blk for eth0
eth0: Tigon3 [partno(BCM95751) rev 4001 PHY(5750)] (PCIX:100MHz:32-bit) 10/100/1000BaseT Ethernet 00:12:3f:89:c1:17
eth0: RXcsums[1] LinkChgREG[1] MIirq[1] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
divert: allocating divert_blk for eth1
eth1: DGE-530T Gigabit Ethernet Adapter
divert: not allocating divert_blk for non-ethernet device sit0
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is off for TX and off for RX.
eth0: no IPv6 routers present
eth1: no IPv6 routers present
eth1: -- ERROR --
eth1: network connection up using port A
eth1: network connection down
eth1: network connection up using port A
eth1: network connection down
eth1: network connection up using port A
eth1: network connection down
eth1: network connection up using port A
eth1: network connection down
eth1: network connection up using port A
 
Both my eth0 and eth1 seem to be working fine now. I must say that I tried several things along the way to this juncture, so perhaps something else I did contributed to my result. I'll never know because I'm not planning to go through this again "as an exercise".
 
Cheers and best of luck to all who travel this path...
 
Jim Golding

Finally got this card working on FC5 with help from the following link...
 
http://www.ubuntuforums.org/showthread.php?t=187770
 
You need to download the kernel sources and install them using the instructions in the link supplied by danleff above and then edit the files:
/usr/src/redhat/BUILD/kernel-2.6.16/linux-2.6.16.noarch/drivers/net/skge.c
 
and
 
/usr/src/redhat/BUILD/kernel-2.6.16/linux-2.6.16.noarch/drivers/net/sky2.c
 
as discussed in the above link.
 
the "kernel-2.6.16/linux-2.6.16.noarch/" may be different depending on the kernel version....
 
then recompile the kernel modules using "make modules", and install these using "make modules_install"
 
You may need edit /etc/modprobe.conf and make sure that the line
'alias eth? sky2' is changed to 'alias eth? skge'
 
Once you've done this the card should work
 
Hope this helps someone
 
Will
 

Nice thread folks! Good troubleshooting on all parts!