1. 19 3月, 2014 2 次提交
  2. 18 3月, 2014 2 次提交
  3. 14 3月, 2014 2 次提交
  4. 13 3月, 2014 3 次提交
  5. 12 3月, 2014 5 次提交
  6. 11 3月, 2014 1 次提交
  7. 10 3月, 2014 1 次提交
    • M
      bnx2: Fix shutdown sequence · a8d9bc2e
      Michael Chan 提交于
      The pci shutdown handler added in:
      
          bnx2: Add pci shutdown handler
          commit 25bfb1dd
      
      created a shutdown down sequence without chip reset if the device was
      never brought up.  This can cause the firmware to shutdown the PHY
      prematurely and cause MMIO read cycles to be unresponsive.  On some
      systems, it may generate NMI in the bnx2's pci shutdown handler.
      
      The fix is to tell the firmware not to shutdown the PHY if there was
      no prior chip reset.
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8d9bc2e
  8. 07 3月, 2014 3 次提交
    • A
      net/mlx4_core: mlx4_init_slave() shouldn't access comm channel before PF is ready · 97989356
      Amir Vadai 提交于
      Currently, the PF call to pci_enable_sriov from the PF probe function
      stalls for 10 seconds times the number of VFs probed on the host. This
      happens because the way for such VFs to determine of the PF
      initialization finished, is by attempting to issue reset on the
      comm-channel and get timeout (after 10s).
      
      The PF probe function is called from a kenernel workqueue, and therefore
      during that time, rcu lock is being held and kernel's workqueue is
      stalled. This blocks other processes that try to use the workqueue
      or rcu lock.  For example, interface renaming which is calling
      rcu_synchronize is blocked, and timedout by systemd.
      
      Changed mlx4_init_slave() to allow VF probed on the host to immediatly
      detect that the PF is not ready, and return EPROBE_DEFER instantly.
      
      Only when the PF finishes the initialization, allow such VFs to
      access the comm channel.
      
      This issue and fix are relevant only for probed VFs on the hypervisor,
      there is no way to pass this information to a VM until comm channel is
      ready, so in a VM, if PF is not ready, the first command will be timedout
      after 10 seconds and return EPROBE_DEFER.
      Signed-off-by: NAmir Vadai <amirv@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      97989356
    • A
      net/mlx4_core: Fix memory access error in mlx4_QUERY_DEV_CAP_wrapper() · 57352ef4
      Amir Vadai 提交于
      Fix a regression introduced by [1]. outbox was accessed instead of
      outbox->buf. Typo was copy-pasted to [2] and [3].
      
      [1] - cc1ade94 mlx4_core: Disable memory windows for virtual functions
      [2] - 4de65803 mlx4_core: Add support for steerable IB UD QPs
      [3] - 7ffdf726 net/mlx4_core: Add basic support for TCP/IP offloads under
            tunneling
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NAmir Vadai <amirv@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      57352ef4
    • A
      ibmveth: Fix endian issues with MAC addresses · d746ca95
      Anton Blanchard 提交于
      The code to load a MAC address into a u64 for passing to the
      hypervisor via a register is broken on little endian.
      
      Create a helper function called ibmveth_encode_mac_addr
      which does the right thing in both big and little endian.
      
      We were storing the MAC address in a long in struct ibmveth_adapter.
      It's never used so remove it - we don't need another place in the
      driver where we create endian issues with MAC addresses.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d746ca95
  9. 06 3月, 2014 3 次提交
    • S
      net: macb: DMA-unmap full rx-buffer · 48330e08
      Soren Brinkmann 提交于
      When allocating RX buffers a fixed size is used, while freeing is based
      on actually received bytes, resulting in the following kernel warning
      when CONFIG_DMA_API_DEBUG is enabled:
       WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1051 check_unmap+0x258/0x894()
       macb e000b000.ethernet: DMA-API: device driver frees DMA memory with different size [device address=0x000000002d170040] [map size=1536 bytes] [unmap size=60 bytes]
       Modules linked in:
       CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc3-xilinx-00220-g49f84081ce4f #65
       [<c001516c>] (unwind_backtrace) from [<c0011df8>] (show_stack+0x10/0x14)
       [<c0011df8>] (show_stack) from [<c03c775c>] (dump_stack+0x7c/0xc8)
       [<c03c775c>] (dump_stack) from [<c00245cc>] (warn_slowpath_common+0x60/0x84)
       [<c00245cc>] (warn_slowpath_common) from [<c0024670>] (warn_slowpath_fmt+0x2c/0x3c)
       [<c0024670>] (warn_slowpath_fmt) from [<c0227d44>] (check_unmap+0x258/0x894)
       [<c0227d44>] (check_unmap) from [<c0228588>] (debug_dma_unmap_page+0x64/0x70)
       [<c0228588>] (debug_dma_unmap_page) from [<c02ab78c>] (gem_rx+0x118/0x170)
       [<c02ab78c>] (gem_rx) from [<c02ac4d4>] (macb_poll+0x24/0x94)
       [<c02ac4d4>] (macb_poll) from [<c031222c>] (net_rx_action+0x6c/0x188)
       [<c031222c>] (net_rx_action) from [<c0028a28>] (__do_softirq+0x108/0x280)
       [<c0028a28>] (__do_softirq) from [<c0028e8c>] (irq_exit+0x84/0xf8)
       [<c0028e8c>] (irq_exit) from [<c000f360>] (handle_IRQ+0x68/0x8c)
       [<c000f360>] (handle_IRQ) from [<c0008528>] (gic_handle_irq+0x3c/0x60)
       [<c0008528>] (gic_handle_irq) from [<c0012904>] (__irq_svc+0x44/0x78)
       Exception stack(0xc056df20 to 0xc056df68)
       df20: 00000001 c0577430 00000000 c0577430 04ce8e0d 00000002 edfce238 00000000
       df40: 04e20f78 00000002 c05981f4 00000000 00000008 c056df68 c0064008 c02d7658
       df60: 20000013 ffffffff
       [<c0012904>] (__irq_svc) from [<c02d7658>] (cpuidle_enter_state+0x54/0xf8)
       [<c02d7658>] (cpuidle_enter_state) from [<c02d77dc>] (cpuidle_idle_call+0xe0/0x138)
       [<c02d77dc>] (cpuidle_idle_call) from [<c000f660>] (arch_cpu_idle+0x8/0x3c)
       [<c000f660>] (arch_cpu_idle) from [<c006bec4>] (cpu_startup_entry+0xbc/0x124)
       [<c006bec4>] (cpu_startup_entry) from [<c053daec>] (start_kernel+0x350/0x3b0)
       ---[ end trace d5fdc38641bd3a11 ]---
       Mapped at:
        [<c0227184>] debug_dma_map_page+0x48/0x11c
        [<c02ab32c>] gem_rx_refill+0x154/0x1f8
        [<c02ac7b4>] macb_open+0x270/0x3e0
        [<c03152e0>] __dev_open+0x7c/0xfc
        [<c031554c>] __dev_change_flags+0x8c/0x140
      
      Fixing this by passing the same size which is passed during mapping the
      memory to the unmap function as well.
      Signed-off-by: NSoren Brinkmann <soren.brinkmann@xilinx.com>
      Reviewed-by: NBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48330e08
    • S
      net: macb: Check DMA mappings for error · 92030908
      Soren Brinkmann 提交于
      With CONFIG_DMA_API_DEBUG enabled the following warning is printed:
       WARNING: CPU: 0 PID: 619 at lib/dma-debug.c:1101 check_unmap+0x758/0x894()
       macb e000b000.ethernet: DMA-API: device driver failed to check map error[device address=0x000000002d171c02] [size=322 bytes] [mapped as single]
       Modules linked in:
       CPU: 0 PID: 619 Comm: udhcpc Not tainted 3.14.0-rc3-xilinx-00219-gd158fc7f #63
       [<c001516c>] (unwind_backtrace) from [<c0011df8>] (show_stack+0x10/0x14)
       [<c0011df8>] (show_stack) from [<c03c7714>] (dump_stack+0x7c/0xc8)
       [<c03c7714>] (dump_stack) from [<c00245cc>] (warn_slowpath_common+0x60/0x84)
       [<c00245cc>] (warn_slowpath_common) from [<c0024670>] (warn_slowpath_fmt+0x2c/0x3c)
       [<c0024670>] (warn_slowpath_fmt) from [<c0228244>] (check_unmap+0x758/0x894)
       [<c0228244>] (check_unmap) from [<c0228588>] (debug_dma_unmap_page+0x64/0x70)
       [<c0228588>] (debug_dma_unmap_page) from [<c02aba64>] (macb_interrupt+0x1f8/0x2dc)
       [<c02aba64>] (macb_interrupt) from [<c006c6e4>] (handle_irq_event_percpu+0x2c/0x178)
       [<c006c6e4>] (handle_irq_event_percpu) from [<c006c86c>] (handle_irq_event+0x3c/0x5c)
       [<c006c86c>] (handle_irq_event) from [<c006f548>] (handle_fasteoi_irq+0xb8/0x100)
       [<c006f548>] (handle_fasteoi_irq) from [<c006c148>] (generic_handle_irq+0x20/0x30)
       [<c006c148>] (generic_handle_irq) from [<c000f35c>] (handle_IRQ+0x64/0x8c)
       [<c000f35c>] (handle_IRQ) from [<c0008528>] (gic_handle_irq+0x3c/0x60)
       [<c0008528>] (gic_handle_irq) from [<c0012904>] (__irq_svc+0x44/0x78)
       Exception stack(0xed197f60 to 0xed197fa8)
       7f60: 00000134 60000013 bd94362e bd94362e be96b37c 00000014 fffffd72 00000122
       7f80: c000ebe4 ed196000 00000000 00000011 c032c0d8 ed197fa8 c0064008 c000ea20
       7fa0: 60000013 ffffffff
       [<c0012904>] (__irq_svc) from [<c000ea20>] (ret_fast_syscall+0x0/0x48)
       ---[ end trace 478f921d0d542d1e ]---
       Mapped at:
        [<c0227184>] debug_dma_map_page+0x48/0x11c
        [<c02aaca0>] macb_start_xmit+0x184/0x2a8
        [<c03143c0>] dev_hard_start_xmit+0x334/0x470
        [<c032c09c>] sch_direct_xmit+0x78/0x2f8
        [<c0314814>] __dev_queue_xmit+0x318/0x708
      
      due to missing checks of the dma mapping. Add the appropriate checks to fix
      this.
      Signed-off-by: NSoren Brinkmann <soren.brinkmann@xilinx.com>
      Reviewed-by: NBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      92030908
    • G
      net/mlx4: Support shutdown() interface · 367d56f7
      Gavin Shan 提交于
      In kexec scenario, we failed to load the mlx4 driver in the
      second kernel because the ownership bit was hold by the first
      kernel without release correctly.
      
      The patch adds shutdown() interface so that the ownership can
      be released correctly in the first kernel. It also helps avoiding
      EEH error happened during boot stage of the second kernel because
      of undesired traffic, which can't be handled by hardware during
      that stage on Power platform.
      Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
      Tested-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      367d56f7
  10. 04 3月, 2014 6 次提交
  11. 03 3月, 2014 2 次提交
  12. 01 3月, 2014 2 次提交
  13. 28 2月, 2014 1 次提交
  14. 27 2月, 2014 1 次提交
  15. 26 2月, 2014 6 次提交