Red Hat Bugzilla – Bug 167768
consider upgradin sk98lin to a recent version
Last modified: 2007-11-30 17:07:20 EST
Description of problem:
Please consider upgrading the sk98lin in RHEL4 (I guess for 4U3 now?) to a more
Version-Release number of selected component (if applicable):
up to 4 U2 beta
As always, thanks :)
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
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:
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]
Add the skge driver...
Test kernels with the above patch are available here:
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
Still could use some test results here... :-)
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?
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
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
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
Is there anything I can do to help with the testing effort or is this a lost