1. 07 5月, 2009 1 次提交
  2. 30 4月, 2009 2 次提交
    • L
      mv643xx_eth: 64bit mib counter read fix · 93af7aca
      Lennert Buytenhek 提交于
      On several mv643xx_eth hardware versions, the two 64bit mib counters
      for 'good octets received' and 'good octets sent' are actually 32bit
      counters, and reading from the upper half of the register has the same
      effect as reading from the lower half of the register: an atomic
      read-and-clear of the entire 32bit counter value.  This can under heavy
      traffic occasionally lead to small numbers being added to the upper
      half of the 64bit mib counter even though no 32bit wrap has occured.
      
      Since we poll the mib counters at least every 30 seconds anyway, we
      might as well just skip the reads of the upper halves of the hardware
      counters without breaking the stats, which this patch does.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      Cc: stable@kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93af7aca
    • L
      mv643xx_eth: OOM handling fixes · 1319ebad
      Lennert Buytenhek 提交于
      Currently, when OOM occurs during rx ring refill, mv643xx_eth will get
      into an infinite loop, due to the refill function setting the OOM bit
      but not clearing the 'rx refill needed' bit for this queue, while the
      calling function (the NAPI poll handler) will call the refill function
      in a loop until the 'rx refill needed' bit goes off, without checking
      the OOM bit.
      
      This patch fixes this by checking the OOM bit in the NAPI poll handler
      before attempting to do rx refill.  This means that once OOM occurs,
      we won't try to do any memory allocations again until the next invocation
      of the poll handler.
      
      While we're at it, change the OOM flag to be a single bit instead of
      one bit per receive queue since OOM is a system state rather than a
      per-queue state, and cancel the OOM timer on entry to the NAPI poll
      handler if it's running to prevent it from firing when we've already
      come out of OOM.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      Cc: stable@kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1319ebad
  3. 09 4月, 2009 1 次提交
  4. 25 3月, 2009 1 次提交
  5. 14 3月, 2009 1 次提交
    • L
      mv643xx_eth: fix unicast address filter corruption on mtu change · 5a893922
      Lennert Buytenhek 提交于
      When mv643xx_eth_open() is called to up an interface, port_start()
      will first re-program the unicast address filter, and then
      re-initialise the PORT_CONFIG register, but that will disable unicast
      promiscuous mode if it was enabled by the unicast address filter setup.
      
      This isn't a problem on ifconfig up, as ->set_rx_mode() will be called
      shortly afterwards which will program the filters again, but it does
      trigger when changing the MTU, which calls mv643xx_eth_stop() and then
      mv643xx_eth_open() by hand to repopulate the receive rings with skbuffs
      of the new size.
      
      Swap the initialisation of the PORT_START register and the call to
      the unicast filter setup function to fix this.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a893922
  6. 25 2月, 2009 4 次提交
  7. 19 2月, 2009 2 次提交
    • S
      net/mv643xx: don't disable the mib timer too early and lock properly · 57e8f26a
      Sebastian Siewior 提交于
      mib_counters_update() also restarts the timer.
      So the timer is dequeued, the stats are read and then the timer is
      enqueued again. This is "okay" unless someone unloads the module.
      The locking here is also broken:
      mib_counters_update() grabs just a simple spinlock. The only thing the
      lock is good for is to protect the timer func against other callers
      namely mv643xx_eth_stop() && mv643xx_eth_get_ethtool_stats(). That means
      if the spinlock is taken via the ethtool path and than the timer kicks
      in then the box will lock up.
      Signed-off-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
      Acked-by: NLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      57e8f26a
    • S
      net/mv643xx: use GFP_ATOMIC while atomic · 82a5bd6a
      Sebastian Siewior 提交于
      dev_set_rx_mode() grabs netif_addr_lock_bh():
      
      |BUG: sleeping function called from invalid context at /home/bigeasy/git/cryptodev-2.6/mm/slub.c:1599
      |in_atomic(): 1, irqs_disabled(): 0, pid: 859, name: ifconfig
      |2 locks held by ifconfig/859:
      | #0:  (rtnl_mutex){--..}, at: [<c0239ccc>] rtnl_lock+0x18/0x20
      | #1:  (_xmit_ETHER){-...}, at: [<c022d094>] dev_set_rx_mode+0x1c/0x30
      |[<c029f118>] (dump_stack+0x0/0x14) from [<c003df28>] (__might_sleep+0x11c/0x13c)
      |[<c003de0c>] (__might_sleep+0x0/0x13c) from [<c00a8854>] (kmem_cache_alloc+0x30/0xd4)
      | r5:c78093a0 r4:c034a47c
      |[<c00a8824>] (kmem_cache_alloc+0x0/0xd4) from [<c01a5fd0>] (mv643xx_eth_set_rx_mode+0x70/0x188)
      |[<c01a5f60>] (mv643xx_eth_set_rx_mode+0x0/0x188) from [<c022ced0>] (__dev_set_rx_mode+0x40/0xac)
      |[<c022ce90>] (__dev_set_rx_mode+0x0/0xac) from [<c022d09c>] (dev_set_rx_mode+0x24/0x30)
      | r6:00001043 r5:c78090f8 r4:c7809000
      |[<c022d078>] (dev_set_rx_mode+0x0/0x30) from [<c02304c4>] (dev_open+0xe4/0x114)
      | r5:c7809350 r4:c7809000
      |[<c02303e0>] (dev_open+0x0/0x114) from [<c022fd18>] (dev_change_flags+0xb0/0x190)
      | r5:00000041 r4:c7809000
      |[<c022fc68>] (dev_change_flags+0x0/0x190) from [<c0270250>] (devinet_ioctl+0x2f0/0x710)
      | r7:c7221e70 r6:c7aadb00 r5:00000000 r4:00000001
      |[<c026ff60>] (devinet_ioctl+0x0/0x710) from [<c02717c8>] (inet_ioctl+0xd4/0x110)
      |[<c02716f4>] (inet_ioctl+0x0/0x110) from [<c021fb74>] (sock_ioctl+0x1f4/0x254)
      | r4:c7242b40
      |[<c021f980>] (sock_ioctl+0x0/0x254) from [<c00b8160>] (vfs_ioctl+0x38/0x98)
      | r6:beec9bb8 r5:00008914 r4:c7242b40
      |[<c00b8128>] (vfs_ioctl+0x0/0x98) from [<c00b873c>] (do_vfs_ioctl+0x484/0x4d4)
      | r6:00008914 r5:c7242b40 r4:c74db1c0
      |[<c00b82b8>] (do_vfs_ioctl+0x0/0x4d4) from [<c00b87cc>] (sys_ioctl+0x40/0x64)
      |[<c00b878c>] (sys_ioctl+0x0/0x64) from [<c00269a0>] (ret_fast_syscall+0x0/0x2c)
      |[42949399.520000]  r7:00000036 r6:beec9c80 r5:00000041 r4:beec9bb8
      Signed-off-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
      Acked-by: NLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      82a5bd6a
  8. 16 2月, 2009 6 次提交
  9. 27 1月, 2009 1 次提交
  10. 20 1月, 2009 3 次提交
  11. 20 11月, 2008 8 次提交
  12. 04 11月, 2008 2 次提交
    • D
      drivers/net: Kill now superfluous ->last_rx stores. · babcda74
      David S. Miller 提交于
      The generic packet receive code takes care of setting
      netdev->last_rx when necessary, for the sake of the
      bonding ARP monitor.
      
      Drivers need not do it any more.
      
      Some cases had to be skipped over because the drivers
      were making use of the ->last_rx value themselves.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      babcda74
    • L
      mv643xx_eth: fix SMI bus access timeouts · ee04448d
      Lennert Buytenhek 提交于
      The mv643xx_eth mii bus implementation uses wait_event_timeout() to
      wait for SMI completion interrupts.
      
      If wait_event_timeout() would return zero, mv643xx_eth would conclude
      that the SMI access timed out, but this is not necessarily true --
      wait_event_timeout() can also return zero in the case where the SMI
      completion interrupt did happen in time but where it took longer than
      the requested timeout for the process performing the SMI access to be
      scheduled again.  This would lead to occasional SMI access timeouts
      when the system would be under heavy load.
      
      The fix is to ignore the return value of wait_event_timeout(), and
      to re-check the SMI done bit after wait_event_timeout() returns to
      determine whether or not the SMI access timed out.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      ee04448d
  13. 28 10月, 2008 1 次提交
  14. 09 10月, 2008 3 次提交
  15. 01 10月, 2008 1 次提交
  16. 20 9月, 2008 2 次提交
  17. 19 9月, 2008 1 次提交