On Wed, Jul 14, 2010 at 01:40:26AM +1000, Jonathan Gray wrote: > On Tue, Jul 13, 2010 at 01:58:50PM +0000, Michael Shalayeff wrote: > > re > > i was testing the diff on our shitz here and it works. > > dual-port Intel PRO/1000 on pci-express and on-boards. > > added a couple more checks where it seemed to make sense. > > those ports having problems before seem to work now. > > cu > > Skipping the parts from the original diff > > > @@ -846,20 +847,21 @@ em_initialize_hardware_bits(struct em_hw *hw) > > > > if (reg_tctl & E1000_TCTL_MULR) > > reg_tarc1 &= ~0x10000000; /* Clear bit 28 if MULR is > > 1b */ > > else > > reg_tarc1 |= 0x10000000; /* Set bit 28 if MULR is > > 0b */ > > > > E1000_WRITE_REG(hw, TARC1, reg_tarc1); > > break; > > case em_82573: > > case em_82574: > > + case em_82575: > > reg_ctrl_ext = E1000_READ_REG(hw, CTRL_EXT); > > reg_ctrl = E1000_READ_REG(hw, CTRL); > > > > reg_ctrl_ext &= ~0x00800000; /* Clear bit 23 */ > > reg_ctrl_ext |= 0x00400000; /* Set bit 22 */ > > reg_ctrl &= ~0x20000000; /* Clear bit 29 */ > > > > E1000_WRITE_REG(hw, CTRL_EXT, reg_ctrl_ext); > > E1000_WRITE_REG(hw, CTRL, reg_ctrl); > > break; > > What are these magic numbers doing and why is it needed on 82575+?
magic io pins (: freebsd does it seems... > > @@ -5944,20 +5946,21 @@ em_rar_set(struct em_hw *hw, > > * while we work. Then, we clear the Address Valid AV bit for all MAC > > * addresses and undo the re-direction to manageability. > > * Now, frames are coming in again, but the MAC won't accept them, so > > * far so good. We now proceed to initialize RSS (if necessary) and > > * configure the Rx unit. Last, we re-enable the AV bits and continue > > * on our merry way. > > */ > > switch (hw->mac_type) { > > case em_82571: > > case em_82572: > > + case em_82575: > > case em_80003es2lan: > > if (hw->leave_av_bit_off == TRUE) > > break; > > default: > > /* Indicate to hardware the Address is Valid. */ > > rar_high |= E1000_RAH_AV; > > break; > > } > > > > E1000_WRITE_REG_ARRAY(hw, RA, (index << 1), rar_low); > > I'm not convinced about this part either, the rar handling > in the most recent version of the Intel code in FreeBSD is > quite different, perhaps more than just this should be changed. well it seems to follow the behaviour of earlier chips so it seems logical to do it same way. cu -- paranoic mickey (my employers have changed but, the name has remained)