Hi all,
I support a couple of machines with an Asus P4P800 motherboard. I
anticipate building more machines with this board, and want it to be
well-supported by Red Hat Linux in the future. The main problem I've run
into so far is the on-board network interface. This board (and its sister
the P4C800) have a 3Com 3C940 Gigabit ethernet chip onboard, which I want
to use both to do a network kickstart and for normal operation, but there
are no drivers for this chip in the RH kernels.
If you go to the Asus website, they give you a driver to download, which
appears to be a 3Com-hacked version of an old sk98lin driver from
SysConnect. (It appears that the logic on the 3C940 is licensed from
SysConnect.) The sk98lin in the
kernel.org kernel, and in the RH kernel,
do not support the 3C940. However, SysKonnect has since provided newer
versions of sk98lin on their website which do support the 3C940:
http://www.syskonnect.com/syskonnect/support/driver/htm/sk98lin.htm
SysKonnect offers a patch for 2.4.21, 2.2.25, and 2.6.0. They also offer an
install package that has a script that attempts to produce sk98lin.o for
your currently-installed kernel. None of these seem appropriate for my
needs (using the latest RHL 9 kernel), although I'm willing to hear
suggestions.
There is a RH Bugzilla bug regarding related issues:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89680
I want to see the latest sk98lin integrated into the Red Hat kernel (for RHL
9, and for the beta or the next release). I'm willing to do work on this
myself. Once I have something that works to my satisfaction, I'll offer it
on my website for others to use. I'll also offer my work to RH, if they're
interested.
My goal is to integrate the latest sk98lin in a way that adheres to RH's
practices and which promotes maintainability and portability to future
kernel releases (until the latest sk98lin gets officially incorporated).
But I need some guidance to arrive at this destination.
I've already made a boot.iso which I can use to kickstart the P4P800. But I
made it in an ugly, unmaintainable way (by hacking the initrd). I think
I've figured out something close to the proper way to do it, but I have
questions.
It appears that what I want to do is to make a patch that can be
incorporated into the kernel src.rpm. Then BOOT, i386, i686, athlon etc.
kernels can be made from this. I have a few questions about how to produce
this patch.
First of all, it appears that I need to pick an appropriate patch serial
number for the specfile. What should I use?
Second, if my patch is applied midway through the patching process, I need
to be careful how I produce the patch, so as not to interfere with later
patches. How do I do this?
Third, I expect that I'll have to pick a custom build string until and
unless RH accepts my patch or builds their own. I suppose if I start with
e.g. kernel-2.4.20-18.9, I could make mine by kernel-2.4.20-18.9.dk.1. Is
that appropriate?
Once I have a patch that applies cleanly, I expect a rebuild of the kernel
packages from the kernel src.rpm will result in all desired kernel
packages, including a BOOT kernel to put on the boot.iso. This leaves one
more question, however: How is the initrd for the boot.iso produced? It
looks like you have to specify each and every driver in the BOOT kernel to
mkinitrd, but I'm not sure that's correct. Surely someone at RH knows
exactly how to do this; I can't find it in the distrubution or on the web,
however.
Thanks very much for any help,
David