***SOLUTION FOUND*** FC2 - Strange Ethernet Behavior
John Krische
john at sysop.com
Thu Aug 19 19:42:32 UTC 2004
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
More information about the fedora-list
mailing list