Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 122393 - kudzu kills networking
kudzu kills networking
Product: Fedora
Classification: Fedora
Component: kudzu (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Depends On:
  Show dependency treegraph
Reported: 2004-05-03 19:08 EDT by Michal Jaegermann
Modified: 2014-03-16 22:44 EDT (History)
1 user (show)

See Also:
Fixed In Version: 1.2.9-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-23 17:11:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
A dmidecode output for an affected machine (17.21 KB, text/plain)
2004-05-03 19:09 EDT, Michal Jaegermann
no flags Details
PCI devices (1.36 KB, text/plain)
2004-05-03 19:10 EDT, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2004-05-03 19:08:17 EDT
Description of problem:

When kudzu is active during startup then a service "network"
ends up with this message:

Bringing up interface eth0:  sk98lin device eth0 does not seem to be
present, delaying initialization.

After that a driver module cannot be removed or reinitialized
in any other way I know apart of rebooting the whole machine
from scratch.

If I turn kudzu off then there is no problem.  This is still
a progress in a comparison with the previuos version of kudzu
which simply was locking tight the whole machine. :-)

SK8V board from ASUSTeK with a single "Processor 142" Opteron.
3c940 built-in ethernet (Marvell) with sk98lin driver.
A full output from 'dmidecode' and 'lspci -tv' is attached.

Version-Release number of selected component (if applicable):

How reproducible:
Every time I tried.
Comment 1 Michal Jaegermann 2004-05-03 19:09:27 EDT
Created attachment 99934 [details]
A dmidecode output for an affected machine
Comment 2 Michal Jaegermann 2004-05-03 19:10:43 EDT
Created attachment 99935 [details]
PCI devices
Comment 3 Bill Nottingham 2004-05-03 23:56:20 EDT
Any kernel messages from the driver?
Comment 4 Michal Jaegermann 2004-05-04 02:01:02 EDT
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.

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
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.
Comment 5 Bill Nottingham 2004-05-04 10:53:59 EDT
What's your /etc/sysconfig/network-scripts/ifcfg-* look like?
Comment 6 Michal Jaegermann 2004-05-04 11:23:54 EDT
The current status for ifcfg-eth0 is:


and for ifcfg-eth1


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.
Comment 7 Bill Nottingham 2004-05-04 11:41:59 EDT
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.
Comment 8 Michal Jaegermann 2004-05-04 11:49:07 EDT
Yes, it does; but it seems to completely disregard in the process
/etc/modprobe.conf screwing up assignments defined there.
Comment 9 Bill Nottingham 2004-05-04 11:53:10 EDT
It should only 'screw things up' in the case of a broken driver, which
you appear to have.
Comment 10 Todd Littlefield 2004-06-01 20:01:25 EDT
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...
Comment 11 Bill Nottingham 2004-06-01 23:48:23 EDT
Todd: 3c59x card, or something else?
Comment 12 Bill Nottingham 2005-09-23 17:11:53 EDT
Closing bugs on older, no longer supported releases. Apologies for any lack of

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,

Note You need to log in before you can comment on or make changes to this bug.