Bug 169690 - Marvell Yukon eth0 works no longer in older kernels after upgrade to kernel 2.6.13-1.1526_FC4
Marvell Yukon eth0 works no longer in older kernels after upgrade to kernel 2...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: John W. Linville
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-01 05:10 EDT by Jan Willem Huijbers
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-01 13:48:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
jwltest-sk98lin-neuter.patch (336 bytes, patch)
2005-10-20 15:20 EDT, John W. Linville
no flags Details | Diff

  None (edit)
Description Jan Willem Huijbers 2005-10-01 05:10:07 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923 Fedora/1.7.12-1.5.1

Description of problem:
Having a dual boot system (Windows XP and Fedora). The hardware is a ASUS 8n1 deluze with AMD processor. Normaly i use yum to keep the system patched.

After the kernel upgrade (2.6.13-1.1526_FC4) i have found that the Marvell Yukon Gigabit Ethernet interface (eth0) only works when i using fedora core 4 2.6.13-1.1526_FC4 kernel. 

When i boot WinXP or an older fedora core 4 kernel i cant get eth) operational. WinXP keeps saying that there is a cabling failure. Older kernels can't get an IP address of the DHCP server. And the BIOS says: Failed because the cable lenght is 178 meters (the cable is in fact no more than 7 or 8 meters).

Swapping the cable  hasn't helped a lot. But that wasn't expecet knowing that when i boot the latest fedora kernel makes the Marvel Yukon interface opational again.

Version-Release number of selected component (if applicable):
kernel 2.6.13-1.1526_FC4

How reproducible:
Always

Steps to Reproduce:
1. Boot latest kernel (Marvel Yukon interface eth0 OK)
2. Boot oder kernel 2.6.12 (eth0 fails)
3. Boot WinXP (cabling problem cant activate eth0)
  

Actual Results:  See above

Expected Results:  Working interface for every OS

Additional info:

What i find strange is that the BIOS is reporting a failed interface with a cable lenght of 170 meters after the fedora core 4 kernel has been come operational. It probably explains why the other operating systems can't use eth0. But in my opinion the bios must have gotten that info from the Marvell Yukon interface driver of the latest kernel.
Comment 1 Dave Jones 2005-10-02 17:05:20 EDT
is this using the sk98lin module ? If so, try the skge module instead, as its an
smaller, improved written-from-scratch driver.
Comment 2 Jan Willem Huijbers 2005-10-03 15:37:14 EDT
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

  
Comment 3 Dave Jones 2005-10-03 18:44:59 EDT
Bill, is there an easy way to tell kudzu "leave it alone!" ? :)
Comment 4 Bill Nottingham 2005-10-03 21:09:06 EDT
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.
Comment 5 John W. Linville 2005-10-04 15:58:57 EDT
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... 
Comment 6 John W. Linville 2005-10-20 15:20:26 EDT
Created attachment 120203 [details]
jwltest-sk98lin-neuter.patch
Comment 7 John W. Linville 2005-10-20 17:37:28 EDT
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! 
Comment 8 Jan Willem Huijbers 2005-10-23 15:43:31 EDT
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 ;-).  
Comment 9 John W. Linville 2005-10-24 11:21:05 EDT
Odd...only my test kernels have that patch...did you try the kernels from 
comment 7? 
Comment 10 Jan Willem Huijbers 2005-10-24 16:22:57 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.