Actually I found that it is sufficient to run make after patching, so that you produce the modules (and btw the kernel too, even if not necessary). Then you can eventually unload the official r8169.ko module, and safely copy the produced /usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.i386/drivers/net/r8169.ko module overwriting the official fedora one under /lib/modules/2.6.18-1.2798.fc6/kernel/drivers/net/r8169.ko and finally running a depmod -a to verify that no problems arise. In this way you - have not to reboot but you can immediately restart network services - you don't need jak (just another kernel tm ;-) but you can use the offical one. - leverage the modularized architecture of linux... I think the only risk could be to have a module produced by a different compiler than the original ones you have on your system if gcc was patched in the mean time... With dmesg you can however see how was build the original fc kernel like:
Linux version 2.6.18-1.2798.fc6 (brewbuilder@hs20-bc2-4.build.redhat.com) (gcc v ersion 4.1.1 20061011 (Red Hat 4.1.1-30)) #1 SMP Mon Oct 16 14:37:32 EDT 2006
Anyway, these steps work for me with the latest 2798 kernel.
I only have a problem with my cd becoming crazy when the network is stressed Tipical examples massive yum updates or scp of great number of files. I get incredible series of Oct 29 17:44:52 tekka kernel: ide: failed opcode was: unknown Oct 29 17:44:52 tekka kernel: hde: drive not ready for command Oct 29 17:44:52 tekka kernel: hde: status error: status=0x58 { DriveReady SeekCo mplete DataRequest } And I can only power off and power on.... the button itself of the cd doesn't make anything. But I think it could be a problem with irqs or the ide controller JMB363 I have, or the cd device itself. ASAP I'm going to buy a sata burner.. and see. Or next panic I would try to trace. I'm seeing that sysrq works also from graphical environment I didn't know this...
HTH Gianluca