1. 27 1月, 2012 11 次提交
  2. 26 1月, 2012 12 次提交
  3. 20 12月, 2011 1 次提交
  4. 09 12月, 2011 1 次提交
  5. 05 12月, 2011 2 次提交
    • B
      e1000e: hitting BUG_ON() from napi_enable · 5f4a780d
      Bruce Allan 提交于
      Based on a patch from Mike McElroy created against the out-of-tree e1000e
      driver:
      
      Hitting the BUG_ON in napi_enable(). Code inspection shows that this can
      only be triggered by calling napi_enable() twice without an intervening
      napi_disable().
      
      I saw the following sequence of events in the stack trace:
      
      1) We simulated a cable pull using an Extreme switch.
      2) e1000_tx_timeout() was entered.
      3) e1000_reset_task() was called. Saw the message from e_err() in the
      console log.
      4) e1000_reinit_locked was called. This function calls e1000_down() and
      e1000_up(). These functions call napi_disable() and napi_enable()
      respectively.
      5) Then on another thread, a monitor task saw carrier was down and executed
      'ip set link down' and 'ip set link up' commands.
      6) Saw the '_E1000_RESETTING'warning fron the e1000_close function.
      7) Either the e1000_open() executed between the e1000_down() and e1000_up()
      calls in step 4 or the e1000_open() call executed after the e1000_up()
      call.  In either case, napi_enable() is called twice which triggers the
      BUG_ON.
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Cc: Mike McElroy <mike.mcelroy@stratus.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      5f4a780d
    • J
      e1000e: Avoid wrong check on TX hang · 09357b00
      Jeff Kirsher 提交于
      Based on the original patch submitted my Michael Wang
      <wangyun@linux.vnet.ibm.com>.
      Descriptors may not be write-back while checking TX hang with flag
      FLAG2_DMA_BURST on.
      So when we detect hang, we just flush the descriptor and detect
      again for once.
      
      -v2 change 1 to true and 0 to false and remove extra ()
      
      CC: Michael Wang <wangyun@linux.vnet.ibm.com>
      CC: Flavio Leitner <fbl@redhat.com>
      Acked-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      09357b00
  6. 30 11月, 2011 1 次提交
  7. 17 11月, 2011 2 次提交
  8. 16 11月, 2011 2 次提交
  9. 15 11月, 2011 1 次提交
  10. 03 11月, 2011 1 次提交
  11. 01 11月, 2011 1 次提交
  12. 19 10月, 2011 1 次提交
  13. 16 10月, 2011 1 次提交
    • B
      e1000e: locking bug introduced by commit 67fd4fcb · a90b412c
      Bruce Allan 提交于
      Commit 67fd4fcb (e1000e: convert to stats64) added the ability to update
      statistics more accurately and on-demand through the net_device_ops
      .ndo_get_stats64 hook, but introduced a locking bug on 82577/8/9 when
      linked at half-duplex (seen on kernels with CONFIG_DEBUG_ATOMIC_SLEEP=y and
      CONFIG_PROVE_LOCKING=y).  The commit introduced code paths that caused a
      mutex to be locked in atomic contexts, e.g. an rcu_read_lock is held when
      irqbalance reads the stats from /sys/class/net/ethX/statistics causing the
      mutex to be locked to read the Phy half-duplex statistics registers.
      
      The mutex was originally introduced to prevent concurrent accesses of
      resources (the NVM and Phy) shared by the driver, firmware and hardware
      a few years back when there was an issue with the NVM getting corrupted.
      It was later split into two mutexes - one for the NVM and one for the Phy
      when it was determined the NVM, unlike the Phy, should not be protected by
      the software/firmware/hardware semaphore (arbitration of which is done in
      part with the SWFLAG bit in the EXTCNF_CTRL register).  This latter
      semaphore should be sufficient to prevent resource contention of the Phy in
      the driver (i.e. the mutex for Phy accesses is not needed), but to be sure
      the mutex is replaced with an atomic bit flag which will warn if any
      contention is possible.
      
      Also add additional debug output to help determine when the sw/fw/hw
      semaphore is owned by the firmware or hardware.
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Reported-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
      a90b412c
  14. 14 10月, 2011 1 次提交
  15. 08 10月, 2011 1 次提交
  16. 07 10月, 2011 1 次提交