***SOLUTION FOUND*** FC2 - Strange Ethernet Behavior

[John Krische]

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