RE: [PATCH v4.4.y, v4.9.y] igb: Remove incorrect "unexpected SYS WRAP" log message

["Keller, Jacob E" <jacob.e.keller@intel.com>]

> -----Original Message-----
> From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
> Sent: Tuesday, February 09, 2021 5:35 PM
> To: netdev@vger.kernel.org
> Cc: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; daichi1.fukui@toshiba.co.jp;
> nobuhiro1.iwamatsu@toshiba.co.jp; Corinna Vinschen <vinschen@redhat.com>;
> Keller, Jacob E <jacob.e.keller@intel.com>; Brown, Aaron F
> <aaron.f.brown@intel.com>; Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Subject: [PATCH v4.4.y, v4.9.y] igb: Remove incorrect "unexpected SYS WRAP" log
> message
> 
> From: Corinna Vinschen <vinschen@redhat.com>
> 
> commit 2643e6e90210e16c978919617170089b7c2164f7 upstream
> 
> TSAUXC.DisableSystime is never set, so SYSTIM runs into a SYS WRAP
> every 1100 secs on 80580/i350/i354 (40 bit SYSTIM) and every 35000
> secs on 80576 (45 bit SYSTIM).
> 
> This wrap event sets the TSICR.SysWrap bit unconditionally.
> 
> However, checking TSIM at interrupt time shows that this event does not
> actually cause the interrupt.  Rather, it's just bycatch while the
> actual interrupt is caused by, for instance, TSICR.TXTS.
> 
> The conclusion is that the SYS WRAP is actually expected, so the
> "unexpected SYS WRAP" message is entirely bogus and just helps to
> confuse users.  Drop it.
> 
> Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
> Acked-by: Jacob Keller <jacob.e.keller@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> Hi,
> 
> A customer reported that the following message appears in the kernel
> logs every 1100s -
> 
>     igb 0000:01:00.1: unexpected SYS WRAP
> 
> As the systems have large uptimes the messages are crowding the logs.
> 
> The message was dropped in
> commit 2643e6e90210e16c ("igb: Remove incorrect "unexpected SYS WRAP" log
> message")
> in v4.14.
> 
> Please consider applying to patch to v4.4 and v4.9 stable kernels - it
> applies cleanly to both the trees.
> 
> Thanks,
> Punit
> 

It makes sense to me for htis to apply to those stable trees as well.

Thanks,
Jake