1. 14 12月, 2011 1 次提交
  2. 06 12月, 2011 3 次提交
    • B
      pasemi_mac: Fix building as module · 65e9d805
      Ben Hutchings 提交于
      Commit ded19add ('pasemic_mac*: Move
      the PA Semi driver') inadvertently split pasemi_mac into two separate
      modules with unresolved symbols.  Change it back into a single module.
      Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      65e9d805
    • F
      r8169: fix Rx index race between FIFO overflow recovery and NAPI handler. · c7c2c39b
      françois romieu 提交于
      Since 92fc43b4, rtl8169_tx_timeout ends up
      resetting Rx and Tx indexes and thus racing with the NAPI handler via
      -> rtl8169_hw_reset
         -> rtl_hw_reset
            -> rtl8169_init_ring_indexes
      
      What about returning to the original state ?
      
      rtl_hw_reset is only used by rtl8169_hw_reset and rtl8169_init_one.
      
      The latter does not need rtl8169_init_ring_indexes because the indexes
      still contain their original values from the newly allocated network
      device private data area (i.e. 0).
      
      rtl8169_hw_reset is used by:
      1. rtl8169_down
         Helper for rtl8169_close. rtl8169_open explicitely inits the indexes
         anyway.
      2. rtl8169_pcierr_interrupt
         Indexes are set by rtl8169_reinit_task.
      3. rtl8169_interrupt
         rtl8169_hw_reset is needed when the device goes down. See 1.
      4. rtl_shutdown
         System shutdown handler. Indexes are irrelevant.
      5. rtl8169_reset_task
         Indexes must be set before rtl_hw_start is called.
      6. rtl8169_tx_timeout
         Indexes should not be set. This is the job of rtl8169_reset_task anyway.
      
      The removal of rtl8169_hw_reset in rtl8169_tx_timeout and its move in
      rtl8169_reset_task do not change the analysis.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: hayeswang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c7c2c39b
    • F
      r8169: Rx FIFO overflow fixes. · 811fd301
      françois romieu 提交于
      Realtek has specified that the post 8168c gigabit chips and the post
      8105e fast ethernet chips recover automatically from a Rx FIFO overflow.
      The driver does not need to clear the RxFIFOOver bit of IntrStatus and
      it should rather avoid messing it.
      
      The implementation deserves some explanation:
      1. events outside of the intr_event bit mask are now ignored. It enforces
         a no-processing policy for the events that either should not be there
         or should be ignored.
      
      2. RxFIFOOver was already ignored in rtl_cfg_infos[RTL_CFG_1] for the
         whole 8168 line of chips with two exceptions:
         - RTL_GIGA_MAC_VER_22 since b5ba6d12
           ("use RxFIFO overflow workaround for 8168c chipset.").
           This one should now be correctly handled.
         - RTL_GIGA_MAC_VER_11 (8168b) which requires a different Rx FIFO
           overflow processing.
      
         Though it does not conform to Realtek suggestion above, the updated
         driver includes no change for RTL_GIGA_MAC_VER_12 and RTL_GIGA_MAC_VER_17.
         Both are 8168b. RTL_GIGA_MAC_VER_12 is common and a bit old so I'd rather
         wait for experimental evidence that the change suggested by Realtek really
         helps or does not hurt in unexpected ways.
      
         Removed case statements in rtl8169_interrupt are only 8168 relevant.
      
      3. RxFIFOOver is masked for post 8105e 810x chips, namely the sole 8105e
         (RTL_GIGA_MAC_VER_30) itself.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: hayeswang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      811fd301
  3. 04 12月, 2011 2 次提交
  4. 01 12月, 2011 1 次提交
  5. 28 11月, 2011 1 次提交
  6. 27 11月, 2011 1 次提交
  7. 24 11月, 2011 5 次提交
    • A
      ehea: Use round_jiffies_relative to align workqueue · 67c170a2
      Anton Blanchard 提交于
      Use round_jiffies_relative to align the ehea workqueue and avoid
      extra wakeups.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      67c170a2
    • A
      ehea: Reduce memory usage in buffer pools · aa9084a0
      Anton Blanchard 提交于
      Now that we enable multiqueue by default the ehea driver is using
      quite a lot of memory for its buffer pools. With 4 queues we
      consume 64MB in the jumbo packet ring, 16MB in the medium packet
      ring and 16MB in the tiny packet ring.
      
      We should only fill the jumbo ring once the MTU is increased but
      for now halve it's size so it consumes 32MB. Also reduce the tiny
      packet ring, with 4 queues we had 16k entries which is overkill.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aa9084a0
    • T
      qlge: fix size of external list for TX address descriptors · 78242853
      Thadeu Lima de Souza Cascardo 提交于
      When transmiting a fragmented skb, qlge fills a descriptor with the
      fragment addresses, after DMA-mapping them. If there are more than eight
      fragments, it will use the eighth descriptor as a pointer to an external
      list. After mapping this external list, called OAL to a structure
      containing more descriptors, it fills it with the extra fragments.
      
      However, considering that systems with pages larger than 8KiB would have
      less than 8 fragments, which was true before commit a715dea3, it
      defined a macro for the OAL size as 0 in those cases.
      
      Now, if a skb with more than 8 fragments (counting skb->data as one
      fragment), this would start overwriting the list of addresses already
      mapped and would make the driver fail to properly unmap the right
      addresses on architectures with pages larger than 8KiB.
      
      Besides that, the list of mappings was one size too small, since it must
      have a mapping for the maxinum number of skb fragments plus one for
      skb->data and another for the OAL. So, even on architectures with page
      sizes 4KiB and 8KiB, a skb with the maximum number of fragments would
      make the driver overwrite its counter for the number of mappings, which,
      again, would make it fail to unmap the mapped DMA addresses.
      Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      78242853
    • Y
      bnx2x: Fix 5461x LED · 1d125bd5
      Yaniv Rosner 提交于
      Fix port identify test on 5461x PHY by driving LEDs through MDIO.
      Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
      Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1d125bd5
    • X
      b44: Use dev_kfree_skb_irq() in b44_tx() · 15ac2b08
      Xander Hover 提交于
      Reported issues when using dev_kfree_skb() on UP systems and
      systems with low numbers of cores.  dev_kfree_skb_irq() will
      properly save IRQ state before freeing the skb.
      
      Tested on 3.1.1 and 3.2_rc2
      
      Example of reproducible trace of kernel 3.1.1
      ------------[ cut here ]------------
         WARNING: at kernel/softirq.c:159 local_bh_enable+0x32/0x79()
         ...
         Pid: 0, comm: swapper Not tainted 3.1.1-gentoo #1
         Call Trace:
          [<c1022970>] warn_slowpath_common+0x65/0x7a
          [<c102699e>] ? local_bh_enable+0x32/0x79
          [<c1022994>] warn_slowpath_null+0xf/0x13
          [<c102699e>] local_bh_enable+0x32/0x79
          [<c134bfd8>] destroy_conntrack+0x7c/0x9b
          [<c134890b>] nf_conntrack_destroy+0x1f/0x26
          [<c132e3a6>] skb_release_head_state+0x74/0x83
          [<c132e286>] __kfree_skb+0xb/0x6b
          [<c132e30a>] consume_skb+0x24/0x26
          [<c127c925>] b44_poll+0xaa/0x449
          [<c1333ca1>] net_rx_action+0x3f/0xea
          [<c1026a44>] __do_softirq+0x5f/0xd5
          [<c10269e5>] ? local_bh_enable+0x79/0x79
          <IRQ>  [<c1026c32>] ? irq_exit+0x34/0x8d
          [<c1003628>] ? do_IRQ+0x74/0x87
          [<c13f5329>] ? common_interrupt+0x29/0x30
          [<c1006e18>] ? default_idle+0x29/0x3e
          [<c10015a7>] ? cpu_idle+0x2f/0x5d
          [<c13e91c5>] ? rest_init+0x79/0x7b
          [<c15c66a9>] ? start_kernel+0x297/0x29c
          [<c15c60b0>] ? i386_start_kernel+0xb0/0xb7
         ---[ end trace 583f33bb1aa207a9 ]---
      Signed-off-by: NXander Hover <LKML@hover.be>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      15ac2b08
  8. 22 11月, 2011 2 次提交
  9. 18 11月, 2011 2 次提交
  10. 17 11月, 2011 15 次提交
  11. 15 11月, 2011 2 次提交
  12. 14 11月, 2011 2 次提交
  13. 10 11月, 2011 2 次提交
  14. 09 11月, 2011 1 次提交