Skip to content

L
linux
Switch branch/tag
  1. 07 Aug, 2012 3 commits
    • Stefan Assmann's avatar
      igb: add delay to allow igb loopback test to succeed on 8086:10c9 · 119b0e03
      Stefan Assmann authored 
      Some 8086:10c9 NICs have a problem completing the ethtool loopback test.
The result looks like this:

ethtool -t eth1
The test result is FAIL
The test extra info:
Register test  (offline)         0
Eeprom test    (offline)         0
Interrupt test (offline)         0
Loopback test  (offline)         13
Link test   (on/offline)         0

A bisect clearly points to commit a95a0744.
However that seems to only trigger the bug. While adding some printk the
problem disappeared, so this might be a timing issue. After some trial and
error I discovered that adding a small delay just before igb_write_phy_reg()
in igb_integrated_phy_loopback() allows the loopback test to succeed.
I was unable to figure out the root cause so far but I expect it to be
somewhere in the following executing path
igb_integrated_phy_loopback
->igb_write_phy_reg_igp
  ->igb_write_phy_reg_mdic
    ->igb_acquire_phy_82575
      ->igb_acquire_swfw_sync_82575

The problem could only be observed on 8086:10c9 NICs so far and not all
of them show the behaviour. I did not restrict the workaround to this
type of NIC as it should do no harm to other igb NICs.

With the patch below the loopback test succeeded 500 times in a row
using a NIC that would otherwise fail.
Signed-off-by: default avatarStefan Assmann <sassmann@kpanic.de>
Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: default avatarPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
      119b0e03
    • Tushar Dave's avatar
      e1000e: 82571 Tx Data Corruption during Tx hang recovery · eca90f55
      Tushar Dave authored 
      A bus trace shows that while executing e1000e_down, TCTL is cleared except
for the PSP bit.  This occurs while in the middle of fetching a TSO packet
since the Tx packet buffer is full at that point. Before the device is
reset, the e1000_watchdog_task starts to run from the middle (it was
apparently pre-empted earlier, although that is not in the trace) and sets
TCTL.EN.  At that point, 82571 transmits the corrupted packet, apparently
because TCTL.MULR was cleared in the middle of fetching a packet, which is
forbidden.

Driver should just clear TCTL.EN in e1000_reset_hw_82571 instead of
clearing the entire register, so as not to change any settings in the
middle of fetching a packet.
Signed-off-by: default avatarTushar Dave <tushar.n.dave@intel.com>
Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: default avatarPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
      eca90f55
    • Tushar Dave's avatar
      e1000e: NIC goes up and immediately goes down · b7ec70be
      Tushar Dave authored 
      Found that commit d478eb44 was a bad commit.
If the link partner is transmitting codeword (even if NULL codeword),
then the RXCW.C bit will be set so check for RXCW.CW is unnecessary.
Ref: RH BZ 840642
Reported-by: default avatarFabio Futigami <ffutigam@redhat.com>
Signed-off-by: default avatarTushar Dave <tushar.n.dave@intel.com>
CC: Marcelo Ricardo Leitner <mleitner@redhat.com>
CC: stable <stable@vger.kernel.org> [2.6.38+]
Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: default avatarPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
      b7ec70be
  3. 06 Aug, 2012 11 commits
  5. 04 Aug, 2012 5 commits
  7. 03 Aug, 2012 8 commits
  9. 02 Aug, 2012 13 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7