All of lore.kernel.org
 help / color / mirror / Atom feed
From: Louis Peens <louis.peens@corigine.com>
To: Michael Chan <michael.chan@broadcom.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, andrew+netdev@lunn.ch,
	pavan.chebbi@broadcom.com, andrew.gospodarek@broadcom.com,
	Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Subject: Re: [PATCH net-next v2 1/4] bnxt_en: Change FW message timeout warning
Date: Tue, 22 Apr 2025 16:33:21 +0200	[thread overview]
Message-ID: <aAeosU3V02vWxD7Z@LouisNoVo> (raw)
In-Reply-To: <20250417172448.1206107-2-michael.chan@broadcom.com>

On Thu, Apr 17, 2025 at 10:24:45AM -0700, Michael Chan wrote:
> The firmware advertises a "hwrm_cmd_max_timeout" value to the driver
> for NVRAM and coredump related functions that can take tens of seconds
> to complete.  The driver polls for the operation to complete under
> mutex and may trigger hung task watchdog warning if the wait is too long.
> To warn the user about this, the driver currently prints a warning if
> this advertised value exceeds 40 seconds:
> 
> Device requests max timeout of %d seconds, may trigger hung task watchdog
> 
> Initially, we chose 40 seconds, well below the kernel's default
> CONFIG_DEFAULT_HUNG_TASK_TIMEOUT (120 seconds) to avoid triggering
> the hung task watchdog.  But 60 seconds is the timeout on most
> production FW and cannot be reduced further.  Change the driver's warning
> threshold to 60 seconds to avoid triggering this warning on all
> production devices.  We also print the warning if the value exceeds
> CONFIG_DEFAULT_HUNG_TASK_TIMEOUT which may be set to architecture
> specific defaults as low as 10 seconds.
> 
> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
> Reviewed-by: Andy Gospodarek <andrew.gospodarek@broadcom.com>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
> ---
> v2: Add check for CONFIG_DEFAULT_HUNG_TASK_TIMEOUT

Hi. Sorry if this is noise - but I have not seen this reported yet. I
think this change introduced a config dependency on 'DEBUG_KERNEL'. As far as I
track the dependency chain:

    DEFAULT_HUNG_TASK_TIMEOUT -> DETECT_HUNG_TASK -> DEBUG_KERNEL.

I have a 'local_defconfig' file which I'm regularly using for compiles,
and I had to add all three these CONFIG settings to it to be able to
compile again, otherwise I encounter this issue:

drivers/net/ethernet/broadcom/bnxt/bnxt.c:10188:21: \
error: 'CONFIG_DEFAULT_HUNG_TASK_TIMEOUT' undeclared (first use in this function)
      max_tmo_secs > CONFIG_DEFAULT_HUNG_TASK_TIMEOUT) {
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Perhaps this was on purpose, but from what I can tell on a quick scan I don't
think it was.

Regards
Louis
> 
> v1: https://lore.kernel.org/netdev/20250415174818.1088646-2-michael.chan@broadcom.com/
> ---

> -- 
> 2.30.1
> 
> 

  reply	other threads:[~2025-04-22 14:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-17 17:24 [PATCH net-next v2 0/4] bnxt_en: Update for net-next Michael Chan
2025-04-17 17:24 ` [PATCH net-next v2 1/4] bnxt_en: Change FW message timeout warning Michael Chan
2025-04-22 14:33   ` Louis Peens [this message]
2025-04-23  6:11     ` Thorsten Leemhuis
2025-04-17 17:24 ` [PATCH net-next v2 2/4] bnxt_en: Report the ethtool coredump length after copying the coredump Michael Chan
2025-04-17 17:24 ` [PATCH net-next v2 3/4] bnxt_en: Remove unused field "ref_count" in struct bnxt_ulp Michael Chan
2025-04-17 17:24 ` [PATCH net-next v2 4/4] bnxt_en: Remove unused macros in bnxt_ulp.h Michael Chan
2025-04-22  9:10 ` [PATCH net-next v2 0/4] bnxt_en: Update for net-next patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aAeosU3V02vWxD7Z@LouisNoVo \
    --to=louis.peens@corigine.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew.gospodarek@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kalesh-anakkur.purayil@broadcom.com \
    --cc=kuba@kernel.org \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pavan.chebbi@broadcom.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.