1. 01 4月, 2018 10 次提交
  2. 27 3月, 2018 1 次提交
  3. 12 3月, 2018 6 次提交
  4. 30 1月, 2018 1 次提交
  5. 26 1月, 2018 1 次提交
  6. 18 1月, 2018 14 次提交
  7. 17 1月, 2018 1 次提交
  8. 11 1月, 2018 1 次提交
  9. 06 1月, 2018 1 次提交
  10. 19 12月, 2017 1 次提交
    • M
      bnxt_en: Use NETIF_F_GRO_HW. · 1054aee8
      Michael Chan 提交于
      Advertise NETIF_F_GRO_HW in hw_features if hardware GRO is supported.
      In bnxt_fix_features(), disable GRO_HW and LRO if current hardware
      configuration does not allow it.  GRO_HW depends on GRO.  GRO_HW is
      also mutually exclusive with LRO.  XDP setup will now rely on
      bnxt_fix_features() to turn off aggregation.  During chip init, turn on
      or off hardware GRO based on NETIF_F_GRO_HW in features flag.
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1054aee8
  11. 09 12月, 2017 1 次提交
    • C
      bnxt_en: Fix sources of spurious netpoll warnings · 2edbdb31
      Calvin Owens 提交于
      After applying 2270bc5d ("bnxt_en: Fix netpoll handling") and
      903649e7 ("bnxt_en: Improve -ENOMEM logic in NAPI poll loop."),
      we still see the following WARN fire:
      
        ------------[ cut here ]------------
        WARNING: CPU: 0 PID: 1875170 at net/core/netpoll.c:165 netpoll_poll_dev+0x15a/0x160
        bnxt_poll+0x0/0xd0 exceeded budget in poll
        <snip>
        Call Trace:
         [<ffffffff814be5cd>] dump_stack+0x4d/0x70
         [<ffffffff8107e013>] __warn+0xd3/0xf0
         [<ffffffff8107e07f>] warn_slowpath_fmt+0x4f/0x60
         [<ffffffff8179519a>] netpoll_poll_dev+0x15a/0x160
         [<ffffffff81795f38>] netpoll_send_skb_on_dev+0x168/0x250
         [<ffffffff817962fc>] netpoll_send_udp+0x2dc/0x440
         [<ffffffff815fa9be>] write_ext_msg+0x20e/0x250
         [<ffffffff810c8125>] call_console_drivers.constprop.23+0xa5/0x110
         [<ffffffff810c9549>] console_unlock+0x339/0x5b0
         [<ffffffff810c9a88>] vprintk_emit+0x2c8/0x450
         [<ffffffff810c9d5f>] vprintk_default+0x1f/0x30
         [<ffffffff81173df5>] printk+0x48/0x50
         [<ffffffffa0197713>] edac_raw_mc_handle_error+0x563/0x5c0 [edac_core]
         [<ffffffffa0197b9b>] edac_mc_handle_error+0x42b/0x6e0 [edac_core]
         [<ffffffffa01c3a60>] sbridge_mce_output_error+0x410/0x10d0 [sb_edac]
         [<ffffffffa01c47cc>] sbridge_check_error+0xac/0x130 [sb_edac]
         [<ffffffffa0197f3c>] edac_mc_workq_function+0x3c/0x90 [edac_core]
         [<ffffffff81095f8b>] process_one_work+0x19b/0x480
         [<ffffffff810967ca>] worker_thread+0x6a/0x520
         [<ffffffff8109c7c4>] kthread+0xe4/0x100
         [<ffffffff81884c52>] ret_from_fork+0x22/0x40
      
      This happens because we increment rx_pkts on -ENOMEM and -EIO, resulting
      in rx_pkts > 0. Fix this by only bumping rx_pkts if we were actually
      given a non-zero budget.
      Signed-off-by: NCalvin Owens <calvinowens@fb.com>
      Acked-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2edbdb31
  12. 08 12月, 2017 1 次提交
  13. 03 12月, 2017 1 次提交