Re: [Intel-wired-lan] [PATCH iwl-net v2] ice: Fix "Unknown bps" during link events

On Thu, Aug 06, 2026 at 06:24:58PM +0200, Lukasz Czapnik wrote:
> From: Jakub Kaminski <[email protected]>
> 
> The driver may display "NIC Link is up Unknown bps" messages during
> link state changes. This occurs when link status and link speed are
> read from different points in time.
> 
> The driver processes link events by receiving an asynchronous ARQ event
> from firmware containing link_up and link_speed values, then performing
> a synchronous AQ query via ice_update_link_info() which overwrites the
> phy.link_info structure, and finally calling ice_link_event() with a
> link_speed parameter while ice_print_link_msg() read link_speed from
> phy.link_info directly.
> 
> ice_print_link_msg() always read link_speed from the phy.link_info
> structure. This caused link status from the ARQ event to be combined
> with link_speed from the later AQ query, mixing information from two
> different points in time. When firmware state changed between these
> moments, inconsistent messages like "Link is up Unknown bps" appeared.
> 
> Add a link_speed parameter to ice_print_link_msg() to ensure link
> status and speed are always taken from the same source and point in
> time.
> 

Hi Lukasz,

Probably this can be addressed when the patch applied.
But I'll point out that git am will truncate the patch description
at this point due to the immediately following scissors ("---").

IOW, Fixes and the other tags should probably appear exactly here.
With the v2 information left below the scissors.

> ---
> 
> v2:
> Remove conditional assignement of local var link_up only during
> UP events. Cache state of both link_up and link_speed for every event.

Thanks for the update.

Reviewed-by: Simon Horman <[email protected]>

> ---
> 
> Fixes: c2a23e00613b ("ice: Refactor link event flow")
> Signed-off-by: Jakub Kaminski <[email protected]>
> Signed-off-by: Lukasz Czapnik <[email protected]>
> Reviewed-by: Aleksandr Loktionov <[email protected]>
> Reviewed-by: Tomasz Lichwala <[email protected]>

...