Re: flash10 vs f10; em(4) now broken in -current in qemu/vbox

Your change would work, but as its shared code and there are other OS's and
their issues to worry about, what I am going to do is a bit different. I am
including
a patch if you would try this now, there will be a full driver update soon.

Anyone set up to test this please post your results here.

Cheers,

Jack


--- /usr/src/sys/dev/e1000/e1000_82540.c    2009-04-09 17:05:46.000000000
-0700
+++ ./e1000_82540.c    2009-06-09 18:47:24.000000000 -0700
_at__at_ -30,7 +30,7 _at__at_
   POSSIBILITY OF SUCH DAMAGE.

 ******************************************************************************/
-/*$FreeBSD: src/sys/dev/e1000/e1000_82540.c,v 1.3 2009/04/10 00:05:46 jfv
Exp $*/
+/*$FreeBSD: $*/

 /*
  * 82540EM Gigabit Ethernet Controller
_at__at_ -57,6 +57,7 _at__at_
 static s32  e1000_setup_copper_link_82540(struct e1000_hw *hw);
 static s32  e1000_setup_fiber_serdes_link_82540(struct e1000_hw *hw);
 static void e1000_power_down_phy_copper_82540(struct e1000_hw *hw);
+static s32  e1000_read_mac_addr_82540(struct e1000_hw *hw);

 /**
  * e1000_init_phy_params_82540 - Init PHY func ptrs.
_at__at_ -229,6 +230,8 _at__at_
     mac->ops.clear_vfta = e1000_clear_vfta_generic;
     /* setting MTA */
     mac->ops.mta_set = e1000_mta_set_generic;
+    /* read mac address */
+    mac->ops.read_mac_addr = e1000_read_mac_addr_82540;
     /* ID LED init */
     mac->ops.id_led_init = e1000_id_led_init_generic;
     /* setup LED */
_at__at_ -676,3 +679,45 _at__at_
     E1000_READ_REG(hw, E1000_MGTPTC);
 }

+/**
+ *  e1000_read_mac_addr_82540 - Read device MAC address
+ *  _at_hw: pointer to the HW structure
+ *
+ *  Reads the device MAC address from the EEPROM and stores the value.
+ *  Since devices with two ports use the same EEPROM, we increment the
+ *  last bit in the MAC address for the second port.
+ *
+ *  This version is being used over generic because of customer issues
+ *  with VmWare and Virtual Box when using generic. It seems in
+ *  the emulated 82545, RAR[0] does NOT have a valid address after a
+ *  reset, this older method works and using this breaks nothing for
+ *  these legacy adapters.
+ **/
+s32 e1000_read_mac_addr_82540(struct e1000_hw *hw)
+{
+    s32  ret_val = E1000_SUCCESS;
+    u16 offset, nvm_data, i;
+
+    DEBUGFUNC("e1000_read_mac_addr");
+
+    for (i = 0; i < ETH_ADDR_LEN; i += 2) {
+        offset = i >> 1;
+        ret_val = hw->nvm.ops.read(hw, offset, 1, &nvm_data);
+        if (ret_val) {
+            DEBUGOUT("NVM Read Error\n");
+            goto out;
+        }
+        hw->mac.perm_addr[i] = (u8)(nvm_data & 0xFF);
+        hw->mac.perm_addr[i+1] = (u8)(nvm_data >> 8);
+    }
+
+    /* Flip last bit of mac address if we're on second port */
+    if (hw->bus.func == E1000_FUNC_1)
+        hw->mac.perm_addr[5] ^= 1;
+
+    for (i = 0; i < ETH_ADDR_LEN; i++)
+        hw->mac.addr[i] = hw->mac.perm_addr[i];
+
+out:
+    return ret_val;
+}




On Tue, Jun 9, 2009 at 12:51 PM, Juergen Lock <nox_at_jelal.kn-bremen.de>wrote:

> On Tue, Jun 09, 2009 at 11:04:46AM -0700, Jack Vogel wrote:
> > There is a change coming that will resolve this, stay tuned.
>
> Cool, thanx! :)
>
>  Btw I posted patches too a few days later, in case you didn't see:
> (I just noticed -current appears to have been dropped from the Cc somehow
> so they only went to -emulation...)
>
> http://lists.freebsd.org/pipermail/freebsd-emulation/2009-June/006292.html
> and for qemu:
>
> http://lists.freebsd.org/pipermail/freebsd-emulation/2009-June/006293.html
>
>  Thanx again,
>         Juergen
>