After applying 2270bc5da3497945 ("bnxt_en: Fix netpoll handling") and
903649e718f80da2 ("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: Calvin Owens <[email protected]>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index c5c38d4..f38160f 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -1883,7 +1883,7 @@ static int bnxt_poll_work(struct bnxt *bp, struct bnxt_napi *bnapi, int budget)
* here forever if we consistently cannot allocate
* buffers.
*/
- else if (rc == -ENOMEM)
+ else if (rc == -ENOMEM && budget)
rx_pkts++;
else if (rc == -EBUSY) /* partial completion */
break;
@@ -1969,7 +1969,7 @@ static int bnxt_poll_nitroa0(struct napi_struct *napi, int budget)
cpu_to_le32(RX_CMPL_ERRORS_CRC_ERROR);
rc = bnxt_rx_pkt(bp, bnapi, &raw_cons, &event);
- if (likely(rc == -EIO))
+ if (likely(rc == -EIO) && budget)
rx_pkts++;
else if (rc == -EBUSY) /* partial completion */
break;
--
2.9.5
On Fri, Dec 8, 2017 at 9:05 AM, Calvin Owens <[email protected]> wrote:
> After applying 2270bc5da3497945 ("bnxt_en: Fix netpoll handling") and
> 903649e718f80da2 ("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: Calvin Owens <[email protected]>
Thanks.
Acked-by: Michael Chan <[email protected]>
From: Michael Chan <[email protected]>
Date: Fri, 8 Dec 2017 09:35:42 -0800
> On Fri, Dec 8, 2017 at 9:05 AM, Calvin Owens <[email protected]> wrote:
>> After applying 2270bc5da3497945 ("bnxt_en: Fix netpoll handling") and
>> 903649e718f80da2 ("bnxt_en: Improve -ENOMEM logic in NAPI poll loop."),
>> we still see the following WARN fire:
...
>> 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: Calvin Owens <[email protected]>
>
> Thanks.
> Acked-by: Michael Chan <[email protected]>
Applied and queued up for -stable.