| Message ID | 1431023830-445-1-git-send-email-mschmidt@redhat.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
> + if (is_kdump_kernel()) { > + ktime_t now = ktime_get_boottime(); > + ktime_t fw_ready_time = ktime_set(5, 0); > + > + if (ktime_before(now, fw_ready_time)) > + msleep(ktime_ms_delta(fw_ready_time, now)); Can't really say I'm familiar with these APIs , but what about the lower msleep limit (is 20 or 50 milliseconds today?)? Shouldn't there be an msleep variant that's good for such cases? [Or is it a non-issue, since at most msleep will be inaccurate] Regardless, the patch itself looks good. > + }-- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dne 7.5.2015 v 21:03 Yuval Mintz napsal(a): >> + if (is_kdump_kernel()) { >> + ktime_t now = ktime_get_boottime(); >> + ktime_t fw_ready_time = ktime_set(5, 0); >> + >> + if (ktime_before(now, fw_ready_time)) >> + msleep(ktime_ms_delta(fw_ready_time, now)); > > Can't really say I'm familiar with these APIs , but what about the lower > msleep limit (is 20 or 50 milliseconds today?)? > Shouldn't there be an msleep variant that's good for such cases? > [Or is it a non-issue, since at most msleep will be inaccurate] msleep(<small_number>) may sleep for a couple of jiffies more than one would expect. I think that's what you mean by "the lower msleep limit". It does not matter. It's not like we have to hit the 5 seconds mark exactly. > Regardless, the patch itself looks good. Thanks, Michal -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Michal Schmidt <mschmidt@redhat.com> Date: Thu, 7 May 2015 20:37:10 +0200 > Commit 12a8541d5c82 "bnx2x: Delay during kdump load" added a 5 seconds > delay to bnx2x's probe function in the kdump case to let the firmware > realize the old driver is gone. > > The problem with the delay is that it is per-device, so if you have > several bnx2x NICs in NPAR mode, the delays can accumulate to minutes. > > Fix it by adjusting the delay so that we do not wait more than > necessary, i.e. no more delaying after 5 seconds of kernel boot time. > > Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c index 556dcc1..fd52ce9 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c @@ -13371,8 +13371,13 @@ static int bnx2x_init_one(struct pci_dev *pdev, /* Management FW 'remembers' living interfaces. Allow it some time * to forget previously living interfaces, allowing a proper re-load. */ - if (is_kdump_kernel()) - msleep(5000); + if (is_kdump_kernel()) { + ktime_t now = ktime_get_boottime(); + ktime_t fw_ready_time = ktime_set(5, 0); + + if (ktime_before(now, fw_ready_time)) + msleep(ktime_ms_delta(fw_ready_time, now)); + } /* An estimated maximum supported CoS number according to the chip * version.
Commit 12a8541d5c82 "bnx2x: Delay during kdump load" added a 5 seconds delay to bnx2x's probe function in the kdump case to let the firmware realize the old driver is gone. The problem with the delay is that it is per-device, so if you have several bnx2x NICs in NPAR mode, the delays can accumulate to minutes. Fix it by adjusting the delay so that we do not wait more than necessary, i.e. no more delaying after 5 seconds of kernel boot time. Signed-off-by: Michal Schmidt <mschmidt@redhat.com> --- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)