Bug 122393 - kudzu kills networking
Summary: kudzu kills networking
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kudzu
Version: rawhide
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-05-03 23:08 UTC by Michal Jaegermann
Modified: 2014-03-17 02:44 UTC (History)
1 user (show)

Fixed In Version: 1.2.9-1
Clone Of:
Environment:
Last Closed: 2005-09-23 21:11:53 UTC
Type: ---
Embargoed:


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

Description Michal Jaegermann 2004-05-03 23:08:17 UTC
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):
kudzu-1.1.58-1

How reproducible:
Every time I tried.

Comment 1 Michal Jaegermann 2004-05-03 23:09:27 UTC
Created attachment 99934 [details]
A dmidecode output for an affected machine

Comment 2 Michal Jaegermann 2004-05-03 23:10:43 UTC
Created attachment 99935 [details]
PCI devices

Comment 3 Bill Nottingham 2004-05-04 03:56:20 UTC
Any kernel messages from the driver?

Comment 4 Michal Jaegermann 2004-05-04 06:01:02 UTC
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.


Comment 5 Bill Nottingham 2004-05-04 14:53:59 UTC
What's your /etc/sysconfig/network-scripts/ifcfg-* look like?

Comment 6 Michal Jaegermann 2004-05-04 15:23:54 UTC
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.

Comment 7 Bill Nottingham 2004-05-04 15:41:59 UTC
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 15:49:07 UTC
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 15:53:10 UTC
It should only 'screw things up' in the case of a broken driver, which
you appear to have.

Comment 10 Todd Littlefield 2004-06-02 00:01:25 UTC
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-02 03:48:23 UTC
Todd: 3c59x card, or something else?

Comment 12 Bill Nottingham 2005-09-23 21:11:53 UTC
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.)


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