linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: marty <marty@goodoldmarty.com>
To: linux-hotplug@vger.kernel.org
Subject: duplicate MAC addresses
Date: Tue, 18 Aug 2009 20:27:04 +0000	[thread overview]
Message-ID: <4A8B0E98.6030202@goodoldmarty.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2110 bytes --]

I got trouble...
(duplicate MAC addresses)

I have a Jetway atom-330 mini-itx board with a builtin NIC and 3-NIC
daughtercard. All 4 NICS are realtek 8169. The software is recent.
The machine works impressively except for described following issues:

The builtin NIC always comes in as eth0 on boot.
The remaining daughtercard NICS have MACS from a different sequence.
On boot all 4 NICS are seen as unique by the kernel and assigned unique
interrupts, (which is very nice).

Enter udev...

On boot udev stalls for 120+ seconds while it executes
i801_smbus functions. This may be a unsupported hardware issue
or other software issue but it is not normal. This may be the problem.

After udev finishes the "70-persistent-net.rules" are borked and eth3 is
assigned the MAC of eth0, causing a duplicate MAC.
On the next boot udev sees the duplicate and renames eth3 to eth3_rename
and the network scripts won't enable it. It becomes useless.

"ip link show" always lists eth3/eth3_rename with the MAC of eth0 as below. Why?

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 00:30:18:ab:4a:8f brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 00:30:18:ab:6a:46 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UNKNOWN qlen 1000
    link/ether 00:30:18:ab:6a:47 brd ff:ff:ff:ff:ff:ff
5: eth3_rename: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:30:18:ab:4a:8f brd ff:ff:ff:ff:ff:ff

What I really don't know is:
After the kernel probes the hardware and acquires the MACs, where
does it keep that info?
Why doesn't udev use that correct probed kernel info for eth3, rather than
configure eth3 with the MAC of eth0? Why probe the hardware trice?
Where is this going wrong? I suspect i801_smbus...

Marty B.
-- 
An artist who is forced to work a specific schedule, is no longer
an artist; he is just hired help. Inspiration cannot be purchased.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

             reply	other threads:[~2009-08-18 20:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-18 20:27 marty [this message]
2009-08-18 21:20 ` duplicate MAC addresses Greg KH
2009-08-18 21:36 ` Matthew Dharm
2009-08-19  0:26 ` marty
2009-08-19  9:19 ` Alan Jenkins
2009-08-19  9:45 ` Rui Santos
2009-08-19 16:51 ` marty
2009-08-23  0:36 ` marty
2009-08-24 18:56 ` John Stoffel
2009-08-24 20:13 ` marty
2009-08-25  8:30 ` Alan Jenkins
2009-08-25  8:31 ` Alan Jenkins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A8B0E98.6030202@goodoldmarty.com \
    --to=marty@goodoldmarty.com \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).