Created attachment 99934 [details]
A dmidecode output for an affected machine

Created attachment 99935 [details]
PCI devices

Any kernel messages from the driver?

Looking closer I actually mis-identified the issue.

In /etc/modprobe.conf there are the following:

alias eth0 sk98lin
alias eth1 e100

and if kudzu does not run then interfaces are asigned that way. One
gets also "Module sk98lin cannot be unloaded due to unsafe usage
in drivers/net/sk98lin/skge.c:791" which prevents later changes.

When kudzu gets into a picture then this shows up on a screen:

Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:  sk98lin device eth0 does not seem to be
present, delaying initialization.
                                                           [FAILED]

Looking closer at dmesg output one can find that:

e100: Intel(R) PRO/100 Network Driver, 3.0.17
e100: Copyright(c) 1999-2004 Intel Corporation
divert: allocating divert_blk for eth0
e100: eth0: e100_probe: addr 0xfde00000, irq 5, MAC addr 00:02:B3:A3:60:E4
sk98lin: Network Device Driver v6.23
(C)Copyright 1999-2004 Marvell(R).
divert: allocating divert_blk for eth1
eth1: 3Com Gigabit LOM (3C940)
      PrefPort:A  RlmtMode:Check Link State
Module sk98lin cannot be unloaded due to unsafe usage in
drivers/net/sk98lin/skge.c:791
divert: freeing divert_blk for eth0

In other words kudzu switched interfaces around.  But if HWADDR
gets added to /etc/sysconfig/network-scripts/ifcfg-eth0 (which
is not the most desirable thing to do here but it could be
acceptable) then on the next startup kudzu throws a big tantrum
that a Marvell card was removed from a configuration.

What's your /etc/sysconfig/network-scripts/ifcfg-* look like?

The current status for ifcfg-eth0 is:

DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
HWADDR=00:0e:a6:4a:bf:fa
USERCTL=no
PEERDNS=no
IPV6INIT=no

and for ifcfg-eth1

DEVICE=eth1
BOOTPROTO=dhcp
ONBOOT=no
TYPE=Ethernet
USERCTL=no
PEERDNS=no
IPV6INIT=no

Before HWADDR was added in ifcfg-eth0 that particular line was simply
missing and other were the same.

After initial unhappiness with "missing hardware", which may scare
unsuspecting newbies, kudzu apparently got over its problems and
now is silent.

Regardless, a quiet reordering of devices is a "misfeature".
Initially I was running without kudzu as previous versions
were wedging the whole machine on an attempt to use it;
but a new version showed up in development updates before I put
together a detailed report.

It merely loads the modules to check their hardware address, so that
you can have persistent device naming. This does require HWADDR lines
for both in ifcfg-*, though.

Yes, it does; but it seems to completely disregard in the process
/etc/modprobe.conf screwing up assignments defined there.

It should only 'screw things up' in the case of a broken driver, which
you appear to have.

I am also having problems with kudzu an networking.  If I turn Kudzu
off, then I can get a connection.  This was an issue for me under
Fedora Core 1 as well.  (It works fine under RH 9 with Kudzu enabled)

This is on a dual Athlon MP system...

Todd: 3c59x card, or something else?

Closing bugs on older, no longer supported releases. Apologies for any lack of
response.

Please attempt to reproduce this bug on a currently supported release, such as
Fedora Core 4. If it persists, please open a new bug in bugzilla.

Note that: a) the message unloading skge means that driver is broken, which
makes it hard to have reliable behavior  b) as of rawhide 1.2.x kudzu, it no
longer loads modules (but they're automatically loaded at startup before then,
anyway.)