Thanks for your reply This is strange. We use currently the Kernel 2.6.30 and in this case the MAC address is read from the EEPROM. We need this feature because the MAC address is defined and written into the EEPROM during our production process.
The reason why we want to swich to a newer Kernel is, because we had a device where the checksum of the EEPROM got invalid during tests and the ethernet device does not get initialized anymore. This behaviour is quite similar to the bug descriped at http://www.thinkwiki.org/wiki/Problem_with_e1000:_EEPROM_Checksum_Is_Not_Valid. In our case we get the invalid checksum with Kernel 2.6.30 (e1000e driver) and the 82573 chip. We hope that this bug got fixed in Kernel 2.6.37. Does anybody know if this bug is fixed in Kernel 2.6.37? But anyway I fear that I got caught in a deadlock situation. The old driver is able to read the MAC address from the EEPROM but has a bug which leads to an invalid EEPROM image. The actual driver, which hopefully solves the checksum problem,is not able to read the MAC address from the EEPROM. Could it be that the alternate MAC address support got disabled because of the problem with the checksum? Martin -----Ursprüngliche Nachricht----- Von: Lindsay, Morgan N [mailto:[email protected]] Gesendet: Freitag, 1. April 2011 20:48 An: Allan, Bruce W; Mangard Martin; [email protected] Cc: Rajagopal, Ramadurai Betreff: RE: Alternate MAC address support disabled for 82573 ? Correct- this is not supported in 82573. I believe this is a feature that is available in only our higher-end server line. -Morgan -----Original Message----- From: Allan, Bruce W Sent: Friday, April 01, 2011 10:24 AM To: Mangard Martin; [email protected] Cc: Lindsay, Morgan N; Rajagopal, Ramadurai Subject: RE: Alternate MAC address support disabled for 82573 ? AFAIK, alternate MAC addresses are not supported on 82573; with the Linux e1000e driver they are only supported on 80003ES2LAN and 82571 LOMs and a couple 82571 mezzanine cards. Adding Morgan and Ram for confirmation of support on 82573. Thanks, Bruce. >-----Original Message----- >From: Mangard Martin [mailto:[email protected]] >Sent: Friday, April 01, 2011 1:38 AM >To: [email protected] >Subject: [E1000-devel] Alternate MAC address support disabled for 82573 ? > >Hello > >We developed a communication device which is euiped with four 82573 >Network chips. The MAC address is read from an external EEPROM. Up to >now we are using the Kernel Version 2.6.30 with its Standard e1000e >driver. The Version of the driver in this Kernel is "0.3.3.4-k4". With >this driver Version we faced the well known problem that the Checksum >of the EEPROM/NVRAM got invalid and the device does not get >initialized. After a little research I found out that higher Kernel >Versions include a patch which disables the L1 ASPM which should fix the >problem. > >In order to solve this issue I downloaded the latest Version of the >driver from the intel homepage >(http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=15817). >This Version is marked as 1.3.10a. > >After I tested this Version I noticed that the MAC address is not read >from the EEPROM. It seems to me that all MAC operations are mapped to >the functions of the 82571 chip. Which disables the usage of the >alternate MAC address for the 82573. This code fragment can also be >found in the driver of the Linux Kernel 2.6.37. > > >static s32 e1000_read_mac_addr_82571(struct e1000_hw *hw) { > s32 ret_val = E1000_SUCCESS; > > if (hw->mac.type == e1000_82571) { // <------- only allow alternate MAC >address for the 82571 ??? > /* > * If there's an alternate MAC address place it in RAR0 > * so that it will override the Si installed default perm > * address. > */ > ret_val = e1000_check_alt_mac_addr_generic(hw); > if (ret_val) > goto out; > } > > ret_val = e1000_read_mac_addr_generic(hw); > >out: > return ret_val; >} > > > >Our communication device is used in an industrial environment which >means that the loose of a network interface caused by an invalid >checksum of the EEPROM is unacceptable. >Is the Checksum problem solved in a recent version of the driver? > >Is there are reason why the alternate MAC address support for the 82573 >chip is disabled in newer Versions of the driver? > > > >Martin Mangard >Software Development / Softwareentwicklung > >AutomationX GmbH >Teslastrasse 8 >A-8074 Grambach bei Graz/Austria >Tel.++43 / 316 / 4000 - 321 >Fax ++43 /316 / 4000 - 39 >http://www.automationX.com <http://www.automationx.com/> >mailto:[email protected] ><mailto:[email protected]> > >Firmenbuchnummer: FN 190475k >Firmenbuchgericht: Landesgericht für ZRS Graz > >This message may contain privileged and/or confidential information. If >you received this email in error or are not the intended recipient, you >may not use, copy, disseminate or distribute it. Do not open any >attachments, delete it immediately from your system and notify the >sender promptly by email that you have done so. Thank you. > > ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
