duplicate MAC addresses

[marty <marty@goodoldmarty.com>]

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

Greg KH wrote:
> > On Tue, Aug 18, 2009 at 04:27:04PM -0400, marty wrote:
>> >> I got trouble...
>> >> (duplicate MAC addresses)
> >
> > That's a bug in your hardware, have you asked your manufacturer to
> > resolve this for you?  That violates the ethernet spec...
> >
> > thanks,
> >
> > greg k-h
> > '

Thanks for responding Greg,
Indeed the MACs should be unique, and they ARE according to kernel.
As I was only guessing can you please be a bit more specific as to
'where' you believe that problem lies?
Then I can contact manufacturer with good information.
Thanks so much,

PS:
Thanks,thanks,thanks,thanks... for the work you have done with linux.

Marty B.

PPS: for Matt Dharm
Your email fragged my ancient email client and I had to do more work. Gaaa...
What's with that I wonder?  I have enough problems right now.
plaintext only, thanks...

> 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 --]