[Intel-wired-lan] [net v2 0/5] igb: fix ptp suspend/resume issue

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On
> Behalf Of Jacob Keller
> Sent: Wednesday, May 11, 2016 4:18 PM
> To: Intel Wired LAN <intel-wired-lan at lists.osuosl.org>
> Cc: Vidya Sagar <sagar.tv at gmail.com>
> Subject: [Intel-wired-lan] [net v2 0/5] igb: fix ptp suspend/resume issue
> 
> This patch series (properly) fixes the issue with igb's workqueue item
> for overflow check from causing a surprise remove event. To do this,
> properly suspend the workqueue items in suspend and then resume them
> again during the resume flow.
> 
> The patch series has a few extra steps to reduce code duplication and
> implement suspend and resume properly, which makes the overall fix a bit
> more complicated, and thus review is welcome.
> 
> A smaller fix would be to implement suspend and resume irrespective of
> the current igb_ptp_stop and igb_ptp_init but this seems more likely to
> introduce bugs especially if either function ever changes in the future.
> 
> In addition, the ptp_flags variable is added mostly to simplify the work
> of writing several complex MAC type checks in the ptp code while doing
> this.
> 
> Jacob Keller (5):
>   igb: introduce ptp_flags variable and use it to replace IGB_FLAG_PTP
>   igb: introduce IGB_PTP_OVERFLOW_CHECK flag
>   igb: introduce igb_ptp_resume function
>   igb: implement igb_ptp_suspend
>   igb: call igb_ptp_suspend/igb_ptp_resume during suspend/resume cycle
> 
>  drivers/net/ethernet/intel/igb/igb.h      |   8 ++-
>  drivers/net/ethernet/intel/igb/igb_main.c |   4 +-
>  drivers/net/ethernet/intel/igb/igb_ptp.c  | 110 ++++++++++++++++-------------
> -
>  3 files changed, 68 insertions(+), 54 deletions(-)

I have not isolated it to the exact patch yet, but one of the patches in this series is causing my systems to lock up with a call trace.  I am currently unable to capture the trace in any form other than a bitmap (which I'll send to Jacob but am not attaching here.)  The trace is really several splats a few minutes apart.  The exact text / procedure calls of the first one seems to vary, but it seems to be in a wakeup routing with "do_page_fault", "? _raw_spin_lock_irq", "? timecounter_read", "? _raw_spin_lock_irqsave", "igb_ptp_gettime_82576" and "igb_ptp_overflow_check" showing up prominently in at least a few instances.  Usually it moves to the next trace before I can get a snapshot.  The follow on trace is where it usually stops with a RIP:, bunch of hex, stack info and a Call Trace saying "arch_cpu_idle", "default_idle_call", "cpu_startup_entry" and "start_secondary" called out.