Bug 169690

is this using the sk98lin module ? If so, try the skge module instead, as its an
smaller, improved written-from-scratch driver.

It was using the sk98lin module. I changed it to use the skge module and the
problem was fixed. 

I had trouble to get the skge module loaded instead of the default sk98lin
module. I have only succeeded through turning off kudzu. 

I removed the file /etc/sysconfig/hwconf. Edited /etc/modprobe.conf (alias eth0
skge instead of alias eth0 sk98lin) and rebooted the system. When kudzu was
operational, the file /etc/modprobe had reversed somehow to (alias eth0
sk98lin). I finally disabled kudzu by: chkconfig --level 0123456 kudzu off. Did
the same changes and rebooted. Now the system boots using the skge module. 

After booting with the skge module and then rebooting winXP showed a working
interface under Win XP. 

The old 2.6.12 kernel failed booting eth0 cause it hasn't a skge module
available. I have no problem with that. But i curious on how to change FEDORA
using the skge module and keep kudzu operational. Thanks

  

Bill, is there an easy way to tell kudzu "leave it alone!" ? :)

Adding the PCI id to the pcitable with a skge mapping may help. If it's pulling
from pcitable, there's only so much that can be done about determining the right
driver.

I think the problem is that both sk98lin and skge have pcitables with 
overlapping entries.  I'm using this patch in my RHEL4 test kernels (which 
include skge): 
 
--- linux-2.6.9/drivers/net/sk98lin/skge.c.orig	2005-09-14 15:25:58.920879254 
-0400 
+++ linux-2.6.9/drivers/net/sk98lin/skge.c	2005-09-14 15:26:32.997341895 
-0400 
@@ -5152,6 +5152,7 @@ static void __devexit skge_remove_one(st 
 } 
  
 static struct pci_device_id skge_pci_tbl[] = { 
+#if 0 /* Use skge instead... */ 
 	{ PCI_VENDOR_ID_3COM, 0x1700, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, 
 	{ PCI_VENDOR_ID_3COM, 0x80eb, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, 
 	{ PCI_VENDOR_ID_SYSKONNECT, 0x4300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, 
@@ -5164,8 +5165,9 @@ static struct pci_device_id skge_pci_tbl 
 #endif 
 	{ PCI_VENDOR_ID_MARVELL, 0x5005, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, 
 	{ PCI_VENDOR_ID_CNET, 0x434e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, 
-	{ PCI_VENDOR_ID_LINKSYS, 0x1032, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, 
 	{ PCI_VENDOR_ID_LINKSYS, 0x1064, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, 
+#endif 
+	{ PCI_VENDOR_ID_LINKSYS, 0x1032, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, 
 	{ 0, } 
 }; 
 
(Also available here:  
http://people.redhat.com/linville/kernels/rhel4/patches/jwltest-sk98lin-neuter.patch) 
 
I don't have any better suggestions... 

Created attachment 120203 [details]
jwltest-sk98lin-neuter.patch

Test kernels w/ the above patch available here: 
 
   http://people.redhat.com/linville/kernels/fc5/ 
 
Feel free to give them a try and verify that the skge driver is now 
perferred...thanks! 

It took a while to verify, but i can say now, that for the fedora development
kernels 2.6.13-1.1622_FC5 and 2.6.13-1.1623_FC5 it works. No problems with kudzu
using the sk98lin module. The skge module is now used.

For verification, i have installed an FC4 minimal instalation on a seperate disk
partition and than i used Yum to update this installation with the development
repo. I had to install the kudzu and the initscripts (rpm -U --nodeps kudzu.rpm
and initscripts.rpm) packages by hand to get yum to update most of the
development packages. Afte that was done. I rebooted the system several times
and had no problems with eth0.

Using lsmod I noticed only the skge module was loaded. No trace of the sk98lin
module ;-).  

Odd...only my test kernels have that patch...did you try the kernels from 
comment 7? 

A possible explanation could be, no sk98lin module available. I 
checked /lib/modules/2.613-1.xxxxxx/kernel/drivers/net/ and there is a skge 
module but no sk98lin module.