Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 6
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 07 8月, 2008 1 次提交
  3. 23 7月, 2008 1 次提交
  5. 18 6月, 2008 6 次提交
  7. 11 6月, 2008 1 次提交
  9. 31 5月, 2008 3 次提交
  11. 22 5月, 2008 1 次提交
  13. 13 5月, 2008 1 次提交
  15. 12 4月, 2008 1 次提交
  17. 03 4月, 2008 1 次提交
  19. 24 2月, 2008 1 次提交
  21. 06 2月, 2008 1 次提交
  23. 03 2月, 2008 2 次提交
  25. 29 1月, 2008 4 次提交
  27. 19 1月, 2008 1 次提交
  29. 13 1月, 2008 2 次提交
  31. 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
  33. 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
  35. 05 12月, 2007 1 次提交
  37. 02 12月, 2007 3 次提交
  39. 24 11月, 2007 1 次提交
  41. 10 11月, 2007 6 次提交