Howdy all.
I have tried a variation on Satish's idea. Satish got me thinking that maybe the updated kernel was not properly interacting with the kernel's modules. Add to that the fact that I discovered I was mistaken in my notes that the problem was happening in kernels 2.6.5 (original fc2) and 2.6.7 (yum update from last week). The problem was happening in 2.6.6 and 2.6.7 - I had no test data on the behavior in 2.6.5. Both newer kernels were gotten from official FC yum update sources.
The solution was therefore to back off on the grub menu to 2.6.5, if for nothing else than to test. I tried exactly that on my dual-boot workstation. Viola, problem disappears. Ethernet traffic & speeds operate at our normal line rates, both inside & outside the LAN. Tried in on our other FC2 boxes, with equal success. Problem solved.
Thanks to everyone who contributed ideas over the last few days! Special thanks to John Meagher and Satish Balay, for contributing key ideas.
SO...
This raises I think an important set of questions for all FC2 users. As I wrote a moment ago, I suspect that the two newer kernels were having trouble interacting with the NIC modules. I'm not sure if that's the case, so I ask these questions, which may be of interest for all users:
When one yum updates the kernel package are all associated modules updated too, or are the modules left alone and thus still associated with the older kernel? If the latter, does that make a difference? (I'm assuming that it very much would) If so, how then does one update kernel modules that have no apparent (official) yum package, without recompiling the kernel from source? If a given module should be found to be buggy, is there likewise a way to replace it via yum rather than a recompile?
Supposing that the answer to the 1st question is "the modules are indeed updated at the same time as the kernel when using a yum update,", can we then suppose that while this is normally the case, that maybe it didn't happen that way for some reason in 2.6.6 nor 2.6.7? Might explain things nicely.
Now, had I followed Satish's recommendation to roll my own kernel... the next time I did a yum update and a newer kernel was available, what would happen? Would yum update to the listed kernel rpm, or stick with my self-compiled custom kernel? Or, suppose the listed yum kernel just happens to have the same version number as my custom-compiled one; what then? Once I understand how that works, I'll feel a lot more comfortable on knowing when to choose to branch from offical packages, and may be able to get the bosses to allow me to stray from official as needed. Doing so on MySQL or an MTA or such is usually no big deal, but when it comes to the kernel itself and a few other key components (like gcc), I want to be absolutely sure that I'm not going to turn a working, bootable system into something nearly useless by doing a simple yum update.
John K.
PS: Satish: I will try your idea of a custom kernel on a laptop I will bring in from home, see what happens. I suspect that a custom compile of any 2.6.5--2.6.8 kernel source will work correctly, and that the problem is in the specifc RPMs.
Satish Balay wrote:
On Thu, 19 Aug 2004, James Wilkinson wrote:
John Krische has been having trouble with Ethernet speeds. I suggested that he try kernel.org kernels, but he wrote:
Yes, these are FC2 kernels, v 2.6.7 something, 494 I think. Thanks for the idea, but for reasons of our own I need to keep these servers on "stock" packages, updates & such from official fedora sources. company policy and all. If it were a machine at home, I'd compile kernel source in a heartbeat.
And there's no chance that you can use kernel.org kernels just for long enough to check that it's a Fedora patch causing the problem? It would at least give us something else to look at.
Why not just try the FC2 testing kernel 521 (which is 2.6.8ish).. Most of the FC2 kernel issus have been upstream issues anyway..
Satish
-- John Krische DB Admin, Ntwk. Admin. BBS Press Service, Inc. A Microsoft Certified Systems Engineer
