Skip to contentSkip to conversation

bnx2x: limit fw delay in kdump to 5s after boot

PATCH Applied Michal Schmidt 3 participants 4 messages May 7, 2015 – May 10, 2015

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 bnx2x: limit fw delay in kdump to 5s after boot

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.

---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c +7 -2
index 556dcc1..fd52ce9 100644
@@ -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.
Signature · 1 line
2.4.0
#1 lore raw

drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c static int bnx2x_init_one(struct pci_dev *pdev, · line 13379

Quoted 6 lines
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c +6 -0
+       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.

Quoted 1 line

+ }

#2 lore raw

Dne 7.5.2015 v 21:03 Yuval Mintz napsal(a):

Quoted 11 lines

drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c static int bnx2x_init_one(struct pci_dev *pdev, · line 13379

Quoted 6 lines
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c +6 -0
+       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.

Quoted 1 line

Regardless, the patch itself looks good.

Thanks,
Michal

maintainer Applied
#3 lore raw
In reply to Michal Schmidt

From: Michal Schmidt <[email protected]>
Date: Thu, 7 May 2015 20:37:10 +0200

Quoted 11 lines

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.

Applied, thanks.