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)
