1. 14 8月, 2008 2 次提交
  2. 07 8月, 2008 1 次提交
  3. 23 7月, 2008 1 次提交
  4. 18 6月, 2008 6 次提交
  5. 11 6月, 2008 1 次提交
  6. 31 5月, 2008 3 次提交
  7. 22 5月, 2008 1 次提交
  8. 13 5月, 2008 1 次提交
  9. 12 4月, 2008 1 次提交
  10. 03 4月, 2008 1 次提交
  11. 24 2月, 2008 1 次提交
  12. 06 2月, 2008 1 次提交
  13. 03 2月, 2008 2 次提交
  14. 29 1月, 2008 4 次提交
  15. 19 1月, 2008 1 次提交
  16. 13 1月, 2008 2 次提交
  17. 09 1月, 2008 1 次提交
    • D
      [NET]: Fix drivers to handle napi_disable() disabling interrupts. · d1d08d12
      David S. Miller 提交于
      When we add the generic napi_disable_pending() breakout
      logic to net_rx_action() it means that napi_disable()
      can cause NAPI poll interrupt events to be disabled.
      
      And this is exactly what we want.  If a napi_disable()
      is pending, and we are looping in the ->poll(), we want
      ->poll() event interrupts to stay disabled and we want
      to complete the NAPI poll ASAP.
      
      When ->poll() break out during device down was being handled on a
      per-driver basis, often these drivers would turn interrupts back on
      when '!netif_running()' was detected.
      
      And this would just cause a reschedule of the NAPI ->poll() in the
      interrupt handler before the napi_disable() could get in there and
      grab the NAPI_STATE_SCHED bit.
      
      The vast majority of drivers don't care if napi_disable() might have
      the side effect of disabling NAPI ->poll() event interrupts.  In all
      such cases, when a napi_disable() is performed, the driver just
      disabled interrupts or is about to.
      
      However there were three exceptions to this in PCNET32, R8169, and
      SKY2.  To fix those cases, at the subsequent napi_enable() points, I
      added code to ensure that the ->poll() interrupt events are enabled in
      the hardware.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NDon Fry <pcnet32@verizon.net>
      d1d08d12
  18. 15 12月, 2007 1 次提交
    • S
      sky2: RX lockup fix · 798fdd07
      Stephen Hemminger 提交于
      I'm using a Marvell 88E8062 on a custom PPC64 blade and ran into RX
      lockups while validating the sky2 driver.  The receive MAC FIFO would
      become stuck during testing with high traffic.  One port of the 88E8062
      would lockup, while the other port remained functional.  Re-inserting
      the sky2 module would not fix the problem - only a power cycle would.
      
      I looked over Marvell's most recent sk98lin driver and it looks like
      they had a "workaround" for the Yukon XL that the sky2 doesn't have yet.
      The sk98lin driver disables the RX MAC FIFO flush feature for all
      revisions of the Yukon XL.
      
      According to skgeinit.c of the sk98lin driver, "Flushing must be enabled
      (needed for ASF see dev. #4.29), but the flushing mask should be
      disabled (see dev. #4.115)".  Nice. I implemented this same change in
      the sky2 driver and verified that the RX lockup I was seeing was
      resolved.
      Signed-off-by: NPeter Tyser <ptyser@xes-inc.com>
      Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      798fdd07
  19. 05 12月, 2007 1 次提交
  20. 02 12月, 2007 3 次提交
  21. 24 11月, 2007 1 次提交
  22. 10 11月, 2007 4 次提交