Bug 167768

For various reasons, this will not be likely to happen. 
 
What device do you want supported?  Would you be interested in the skge and/or 
sky2 drivers? 

John,


I'm used sk98lin because that was what the installer (4U1) suggested. The GE 
chip is reported 88E8001 by lspci (vendor:device id is 11ab:4320)

On Shuttle SB83G systems (and others according to Marvell) the drivers supplied
by RHEL4 do not work properly - there are errors constantly printed in the
syslog and interface counters are always zero.

There been various discussions regarding the issue:

<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136158>
<http://bugzilla.kernel.org/show_bug.cgi?id=3598>

According to Marvell, version 8.24 of the sk98lin driver fixes the issue. I
applied it as a patch to the kernel*.src.rpm and it seems to compile cleanly. I
also enabled NAPI. I've got no trouble with it in the lab using both 4U1 and the
4U2 beta kernel while transfering data at high rates to/from the host.
 
As far as I could tell, there weren't any sk98lin affecting patches in the RHEL4
kernel with the exception of one (davej's MODULE_DEVICE_TABLE entry patch)

Please let me know if you need more information, thanks :)

Created attachment 118825 [details]
jwltest-skge.patch

Add the skge driver...

Test kernels with the above patch are available here: 
 
   http://people.redhat.com/linville/kernels/rhel4/ 
 
These include the skge driver as an alternative to the sk98lin driver.  You 
may need to edit /etc/modprobe.conf and change instances of "sk98lin" to 
"skge" in order to use this driver.  Please give these kernels a try and post 
the results...thanks! 

Still could use some test results here... :-) 

Hi John,


I'm happy with the sk98lin driver. There haven't been any problems with it on
any of the systems requiring it. Is there something wrong with that particular
driver or is there another reason why you would prefer to switch to skge instead?

Thanks :)

The sk98lin driver has fallen out of favor with the Linux community and is 
essentially unmaintained.  While Marvell does have an update version available 
for download, the version in the Linux kernel (and in Fedora and RHEL) does 
not support a lot of newer variations of the hardware, particularly the 
Yukon-II chips. 
 
The sk98lin driver simply will not be updated in a Red Hat kernel unless/until 
the upstream sk98lin situation changes.  Even if I wanted to update it, I 
would be severely beaten by my peers... :-) 
 
If at all possible, please try the skge driver.  It should work with any 
hardware currently covered by the sk98lin driver.  Please post any test 
results (positive or negative) here...thanks! 

Closed due to lack of response.  Please reopen when the skge and/or sky2 
testing results become available.  sk98lin will NOT be upgraded in RHEL4. 

I'm not sure if you'll still take feedback here since you closed the bug, however, 
I recently purchased a DLink DGE-530T because is was the only card available at 
the one store in town and I was hoping it might work with RHEL4.

The system is RHEL4 U4 and it detected the card, and attempted to use the sky2 
driver, but this driver simply returned an error that the specific chip ID in 
question (0xB1) was not supported.  Further invesitgation turned up your pages 
with your test kernels and indicated the card should be supported with the skge 
driver.

I attempted to use your kernels, and modified the modprobe.conf to load the skge 
module instead of the sky2 module.  The 1.6 version of the skge module did 
recognize the card, and allowed me to bring the interface up, however, it would 
not pass any traffic.  The RX count on the interface would increase so it appeared 
to be receiving traffic, however, the TX count remained at zero.

I was able to get the card to work by downloading, complining, and installing the 
updated sk98lin driver from the http://www.syskonnect.de/ support website so I 
know the hardware is fine.  Actually performance seems quite good.

I attempted to compile a newer skge driver from the 2.6.19-pre2 kernels but there 
were too many changes and I didn't have time to attempt to hack it enough to 
compile.

Is there anything I can do to help with the testing effort or is this a lost 
cause?

Thanks,
Tom