Description of problem: The current version of this driver from SysKonnect is 6.05 while a driver included in a kernel is 6.02 and it does not seem to have an idea how to handle "YUKON-Lite" cards. Here is a difference of a header of 'skversion.h' files from a driver in a kernel and the current version @@ -2,16 +2,15 @@ * * Name: version.h * Project: GEnesis, PCI Gigabit Ethernet Adapter - * Version: $Revision: 1.1.2.1 $ - * Date: $Date: 2001/09/05 13:38:30 $ + * Version: $Revision: 1.4 $ + * Date: $Date: 2003/02/25 14:16:40 $ * Purpose: SK specific Error log support * Version-Release number of selected component (if applicable): 2.4.20-9
Correct - sk haven't submitted their new drivers to the kernel proper yet however as far as I know, or I'd be merging them 8)
A version of the driver included in a kernel, apart of this detail that it misses current cards, has also that nasty habit that if you will try to take down a corresponding interface with a cable unplugged, or with "the other end" powered down, then it hangs the whole machine. In particular easy to trip over in a shutdown. This "feature" was inherited by a version 6.05 mentioned in the original report. The latest one I was testing, namely 6.10, lost it and it also fixed problems in a broadcast UDP traffic. How to make Syskonnect to submit that driver other than making it available on their ftp I have no idea. It is under GPL.
I just spoke to Terry Appling at SysKonnect's U.S. tech support office (phone number found through the sk website). He was very understanding and helpful. They will be looking into submitting the latest sk98lin drivers directly to Alan, so hopefully we'll see them soon in the -ac, Red Hat, and stock kernels. It would be great if the latest drivers could be added to new RHL9 kernels and to the new beta.
I should add: this updated driver has interest not only for (I presume) enterprise customers who buy a sk card, but also for desktop customers. The popular Asus P4C800 and P4P800 desktop motherboards have onboard GigE that is supported by the updated driver, but not by the driver currently in the stock or Red Hat kernels. This becomes an issue especially when you try to do a network kickstart using the stock Red Hat tools. I ended up making a custom boot.iso, which was a real pain, and which resulted in a CD that boots the P4P800, but not an older, normally-supported card. (I'm not sure how I messed up, because the boot.iso customization is not a simple or well-documented process. :)
driver maintainers are: P: Mirko Lindner M: mlindner P: Ralph Roesler M: rroesler and you can get latest at: http://www.syskonnect.com/syskonnect/support/driver/htm/sk98lin.htm
I've made sk98lin driver disks for RHL9. It should be easy to make them for other versions of RHL and FC. See: http://www.klab.caltech.edu/~kewley/driverdisk/sk98lin.html I also wrote up some general instructions for making driver disks, using Doug Ledford's kit: http://www.klab.caltech.edu/~kewley/driverdisk/dd.html I believe that a recent version of sk98lin is included in kernel 2.4.22 (or 2.4.22-ac, so these driver disks may have a limited lifetime. :) I haven't actually tried 2.4.22 yet, myself. David
Version in FC2 (6.24?) seems to support Yukon-Lite cards. Is this still a problem in FC2?
I have never uses Yukon-Lite cards, and I no longer manage machines with the Asus motherboards that I complained about here. So I can't verify whether the latest FC2 kernel works fine for the issues in this bug. I see the latest FC2 kernel, 2.6.8-1.521, has sk98lin version 6.23 released 2004.02.13 (see drivers/net/sk98lin/h/skversion.h). Meanwhile SK has version 7.04 on their website (see http://www.syskonnect.com/syskonnect/support/driver/). I can find no changelog or equivalent, but the diff between the FC2 version and 7.04 gives several hundred new or changed lines. It'd be great to have 7.04 upstream, but that would require users to bug SK again. Based on improvements from 6.02 to 6.23, I would say that you can close this bug if you get no other comments.
No comments after a week...
> No comments after a week... What comments do you expect other than a comment #8? Something truly relevant to the original report could have been said over a year ago, or so, and this is mostly a historical issue by now.