Bug 140252

Summary: udev turns eth1 into devXXXX causing 99% cpu ifup scripts
Product: [Fedora] Fedora Reporter: Paul Wouters <paul>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED CURRENTRELEASE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: khanreaper, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: FC4 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-10-03 20:09:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
ifcfg-eth1 none

Description Paul Wouters 2004-11-21 19:41:45 UTC
Description of problem:
I notice my pci-pcmcia (yenta_socket0 with prism2 card in it is pporly
recognised. For a few seconds it is called eth1 when using ifconfig,
and the kernel dmesg shows:

cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x200-0x207 0x290-0x297
0x378-0x37f 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
cs: memory probe 0xa0000000-0xa0ffffff: clean.
orinoco 0.13e (David Gibson <hermes@gibson.dropbear.id.au>, Pavel
Roskin <proski@gnu.org>, et al)
orinoco_cs 0.13e (David Gibson <hermes@gibson.dropbear.id.au>, Pavel
Roskin <proski@gnu.org>, et al)
divert: allocating divert_blk for eth1
eth1: Station identity 001f:0004:0001:0003
eth1: Looks like an Intersil firmware version 1.3.4
eth1: Ad-hoc demo mode supported
eth1: IEEE standard IBSS ad-hoc mode supported
eth1: WEP supported, 104-bit key
eth1: MAC address 00:90:4B:01:95:9B
eth1: Station name "Prism  I"
eth1: ready
eth1: index 0x01: Vcc 3.3, irq 5, io 0x0100-0x013f
divert: freeing divert_blk for dev9732

then I end up with a devXXXX device, even if I add a rule to the
udev rules like:

KERNEL="eth*", SYSFS{address}="my-mac-address", NAME="eth1"

ifup processes take lots of cpu hanging. I had to disable pcmcia
completely and wire up my machine to eth0, a regular ethernet card
that works fine (e100)

Version-Release number of selected component (if applicable):
(but tried manually installing udev-046 as well)

How reproducible:
not entirely sure how to reproduce.

Comment 1 Harald Hoyer 2004-11-22 10:53:36 UTC
the device renaming happens in ifup, because you specified HWADDR in
the ifcfg-eth1 file.

Comment 2 Paul Wouters 2004-11-22 13:12:59 UTC
ahh indeed. Because of the dual interfaces, in the past I had tried
to force the proper ethx using HWADDR in the ifcfg-eth1 file. But it
was pointing to the address of the eth0 card (as per modprobe.conf)

So the bug changes to 'prevent ifup looping in 99% cpu mode when
stupid people mix up modprobe.conf and HWADDR paramters around :)

Comment 3 Bill Nottingham 2004-11-22 16:13:06 UTC
Can you attach your ifcfg-* files and /etc/modprobe.conf from when
this happens?

Comment 4 Paul Wouters 2004-11-22 17:34:04 UTC
Created attachment 107200 [details]

Comment 5 Paul Wouters 2004-11-22 17:35:17 UTC
Created attachment 107201 [details]

Comment 6 Paul Wouters 2004-11-22 17:37:18 UTC
Created attachment 107202 [details]

Comment 7 Paul Wouters 2004-11-22 17:38:21 UTC
not sure if onboot=no solved the ifup problem, I dont think it did,
but originally it had onboot=yes

Comment 8 Bill Nottingham 2005-10-03 20:09:54 UTC
This should work in FC4, provided that HWADDR is in all the ifcfg-X scripts
(there was a bug fixed with respect to handling commented HWADDR lines, which
you did have one of.)