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:
signature.asc
Description: OpenPGP digital signature
