On 8/18/09, marty <marty@xxxxxxxxxxxxxxxx> wrote: > 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... > The long boot delay with i801_smbus sounds like a bug I've seen elsewhere. It's not necessarily related to your MAC woes, but it is the sort of thing that could cause weird "undefined behaviour": <http://bugzilla.kernel.org/show_bug.cgi?id=13620> / <http://bugzilla.kernel.org/show_bug.cgi?id=12376> Have you tried not loading the driver? E.g. echo "blacklist i2c_i801" >> /etc/modprobe.d/blacklist.conf which should prevent it from being loaded by udev. If the kernel version is < 2.6.30 then booting with "acpi_enforce_resource=strict" will hopefully have the same effect as the blacklist. 2.6.30 made this option the default, but then broke the feature; I think it will be fixed in 2.6.32. Regards Alan -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
