Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753153AbZIAH7w (ORCPT ); Tue, 1 Sep 2009 03:59:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753083AbZIAH7v (ORCPT ); Tue, 1 Sep 2009 03:59:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38013 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751781AbZIAH7u (ORCPT ); Tue, 1 Sep 2009 03:59:50 -0400 Message-ID: <4A9CD443.6030603@redhat.com> Date: Tue, 01 Sep 2009 09:58:59 +0200 From: Ivan Vecera User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Alan Jenkins CC: Francois Romieu , marty , linux-hotplug@vger.kernel.org, netdev , linux-kernel , Mikael Pettersson Subject: Re: r8189 mac address changes persist across reboot (was: duplicate MAC addresses) References: <9b2b86520908230314q37d07da6mbde9dc48ad5a17ce@mail.gmail.com> In-Reply-To: <9b2b86520908230314q37d07da6mbde9dc48ad5a17ce@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4462 Lines: 98 Alan Jenkins napsal(a): > On 8/23/09, marty wrote: >> 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... >> I have resolved that problem as of today. I found this was caused >> by the software I had been using. If a hardware issue remains, it is moot. >> >> The bonding driver/utilities normally sets the bond address to the MAC of >> the >> first NIC. But it also set the MAC of the slave (eth3) to the MAC of the >> first >> NIC. This persists through reboots so that is how my MACs got duplicated. >> >> Resetting the MAC corrected those problems and everything works fine now. >> >> Marty B. > > Hmm. > > "To restore your slaves' MAC addresses, you need to detach them > from the bond (`ifenslave -d bond0 eth0'). The bonding driver will > then restore the MAC addresses that the slaves had before they were > enslaved." > > In which case one would hope that a clean shutdown would restore the > MAC addresses in the same way as ifenslave -d. > > I found that snippet via Google, which pointed me to the 2.4 version > of the same document [1]. It suggests that your hardware or driver is > a little unusual. > > "To restore your slaves' MAC addresses, you need to detach them > from the bond (`ifenslave -d bond0 eth0'), set them down > (`ifconfig eth0 down'), unload the drivers (`rmmod 3c59x', for > example) and reload them to get the MAC addresses from their > eeproms." > > So other drivers would not have this problem, because they always > reset the MAC address at load time. That would explain why the the > kernel doesn't bother resetting the MAC addresses on shutdown. > > Looking at r8169.c confirms this. It doesn't appear to initialize the > MAC address register from elsewhere; it just uses the current value. > It will also report this initial value as the "permanent" MAC address, > which your report suggests is wrong. I think your problem is a bug in > r8169. > > Francois, I found a datasheet for the 8139; it was claimed to be > similar and it does indeed appear so. The datasheet suggests that the > driver needs to provoke "auto-load" from the EEPROM at load time. > Could you please have a look at fixing this, so that MAC address > changes do not persist over a reboot? > Using auto-loading method is not possible for all new Realtek products (mainly for PCI-E chipsets). I asked the Realtek engineers and this is the answer: Q: Is it possible to use HW register at offset 50h to reload the MAC address from EEPROM or somewhere else? I mean the usage of Auto-load mode (bits EEM1=0 and EEM0=1 in 50h HW reg). A: Current new LANs don't load mac address throught autoload command. You need to read it out from external eeprom or internal efuse then put it back to ID0~ID5. So you need to read the MAC address from the EEPROM and then write it into ID0-ID5 registers. I already created the patch that initializes the MAC address from EEPROM but there were some issues with this patch so it was reverted. Mikael reported that the MAC address from its adapter (on Thecus n2100) is read only partly (first 3 bytes were correct but the rest were zeros). Later we found that the MAC address is correct and there are really 3 correct bytes + 3 zeros in EEPROM. The Thecus n2100 system probably uses only these 3 bytes and the remaining 3 bytes fills in by itself (they are probably stored somewhere in the firmware). I have tested my patch with several different realtek NICs without any problem but what should we do with embedded system like the n2100 that initializes the MAC in other way. There are 2 possibilities: 1) There could be an additional module param to enable/disable the MAC initialization 2) The MAC address read from EEPROM will be checked against the current MAC address in ID0-5 registers. And the current MAC will be replaced by the one from EEPROM only if the first 3 bytes (OUI part) are different. Francois, what do you think about it? Regards, Ivan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/