| Message ID | 20201124043407.2127285-1-sukadev@linux.ibm.com (mailing list archive) |
|---|---|
| State | Deferred |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net-next,v2,1/1] ibmvnic: add some debugs | expand |
| Context | Check | Description |
|---|---|---|
| netdev/apply | fail | Patch does not apply to net-next |
| netdev/tree_selection | success | Clearly marked for net-next |
On Mon, 23 Nov 2020 20:34:07 -0800 Sukadev Bhattiprolu wrote: > We sometimes run into situations where a soft/hard reset of the adapter > takes a long time or fails to complete. Having additional messages that > include important adapter state info will hopefully help understand what > is happening, reduce the guess work and minimize requests to reproduce > problems with debug patches. > > Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com> > --- > > Changelog[v2] > [Jakub Kacinski] Change an netdev_err() to netdev_info()? Changed > to netdev_dbg() instead. Also sending to net rather than net-next. > > Note: this debug patch is based on following bug fixes and a feature > from Dany Madden and Lijun Pan: In which case you need to wait for these prerequisites to be in net-next and then repost.
Jakub Kicinski [kuba@kernel.org] wrote: > On Mon, 23 Nov 2020 20:34:07 -0800 Sukadev Bhattiprolu wrote: > > We sometimes run into situations where a soft/hard reset of the adapter > > takes a long time or fails to complete. Having additional messages that > > include important adapter state info will hopefully help understand what > > is happening, reduce the guess work and minimize requests to reproduce > > problems with debug patches. > > > > Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com> > > --- > > > > Changelog[v2] > > [Jakub Kacinski] Change an netdev_err() to netdev_info()? Changed > > to netdev_dbg() instead. Also sending to net rather than net-next. > > > > Note: this debug patch is based on following bug fixes and a feature > > from Dany Madden and Lijun Pan: > > In which case you need to wait for these prerequisites to be in net-next > and then repost. Jakub, A process question that I could not find an answer to on the netdev FAQ. With commit 98c41f04a67a ("ibmvnic: reduce wait for completion time") the pre-requisites for the above patch are in the net tree but not yet in net-next. When net-next is open, does it get periodically rebased to net tree or does the rebase happen only when net-next closes? If latter, should I resend above patch based on net-next and handle a manual merge during the rebase? (There is no functional dependence on the pre-reqs - just needs a manual merge). Thanks, Sukadev
On Wed, 2 Dec 2020 19:33:19 -0800 Sukadev Bhattiprolu wrote: > Jakub Kicinski [kuba@kernel.org] wrote: > > On Mon, 23 Nov 2020 20:34:07 -0800 Sukadev Bhattiprolu wrote: > > > We sometimes run into situations where a soft/hard reset of the adapter > > > takes a long time or fails to complete. Having additional messages that > > > include important adapter state info will hopefully help understand what > > > is happening, reduce the guess work and minimize requests to reproduce > > > problems with debug patches. > > > > > > Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com> > > > --- > > > > > > Changelog[v2] > > > [Jakub Kacinski] Change an netdev_err() to netdev_info()? Changed > > > to netdev_dbg() instead. Also sending to net rather than net-next. > > > > > > Note: this debug patch is based on following bug fixes and a feature > > > from Dany Madden and Lijun Pan: > > > > In which case you need to wait for these prerequisites to be in net-next > > and then repost. > > Jakub, > > A process question that I could not find an answer to on the netdev FAQ. > > With commit 98c41f04a67a ("ibmvnic: reduce wait for completion time") > the pre-requisites for the above patch are in the net tree but not yet > in net-next. > > When net-next is open, does it get periodically rebased to net tree or > does the rebase happen only when net-next closes? net is merged into net-next after each PR with fixes we send to Linus, so they are merged periodically. There is no schedule for it but I usually send a PR on Thu and merge things late in the day on Thu or early Fri PST. > If latter, should I resend above patch based on net-next and handle a > manual merge during the rebase? (There is no functional dependence on > the pre-reqs - just needs a manual merge).
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c index 5cb4cfabe2de..e605a08c6551 100644 --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -406,6 +406,8 @@ static void replenish_pools(struct ibmvnic_adapter *adapter) if (adapter->rx_pool[i].active) replenish_rx_pool(adapter, &adapter->rx_pool[i]); } + + netdev_dbg(adapter->netdev, "Replenished %d pools\n", i); } static void release_stats_buffers(struct ibmvnic_adapter *adapter) @@ -911,6 +913,7 @@ static int ibmvnic_login(struct net_device *netdev) __ibmvnic_set_mac(netdev, adapter->mac_addr); + netdev_dbg(netdev, "[S:%d] Login succeeded\n", adapter->state); return 0; } @@ -1377,6 +1380,10 @@ static int ibmvnic_close(struct net_device *netdev) struct ibmvnic_adapter *adapter = netdev_priv(netdev); int rc; + netdev_dbg(netdev, "[S:%d FOP:%d FRR:%d] Closing\n", + adapter->state, adapter->failover_pending, + adapter->force_reset_recovery); + /* If device failover is pending, just set device state and return. * Device operation will be handled by reset routine. */ @@ -1969,8 +1976,10 @@ static int do_reset(struct ibmvnic_adapter *adapter, struct net_device *netdev = adapter->netdev; int i, rc; - netdev_dbg(adapter->netdev, "Re-setting driver (%d)\n", - rwi->reset_reason); + netdev_dbg(adapter->netdev, + "[S:%d FOP:%d] Reset reason %d, reset_state %d\n", + adapter->state, adapter->failover_pending, + rwi->reset_reason, reset_state); rtnl_lock(); /* @@ -2129,6 +2138,8 @@ static int do_reset(struct ibmvnic_adapter *adapter, adapter->state = reset_state; rtnl_unlock(); + netdev_dbg(adapter->netdev, "[S:%d FOP:%d] Reset done, rc %d\n", + adapter->state, adapter->failover_pending, rc); return rc; } @@ -2198,6 +2209,8 @@ static int do_hard_reset(struct ibmvnic_adapter *adapter, /* restore adapter state if reset failed */ if (rc) adapter->state = reset_state; + netdev_dbg(adapter->netdev, "[S:%d FOP:%d] Hard reset done, rc %d\n", + adapter->state, adapter->failover_pending, rc); return rc; } @@ -2308,6 +2321,11 @@ static void __ibmvnic_reset(struct work_struct *work) } clear_bit_unlock(0, &adapter->resetting); + + netdev_dbg(adapter->netdev, + "[S:%d FRR:%d WFR:%d] Done processing resets\n", + adapter->state, adapter->force_reset_recovery, + adapter->wait_for_reset); } static void __ibmvnic_delayed_reset(struct work_struct *work) @@ -2353,7 +2371,8 @@ static int ibmvnic_reset(struct ibmvnic_adapter *adapter, list_for_each(entry, &adapter->rwi_list) { tmp = list_entry(entry, struct ibmvnic_rwi, list); if (tmp->reset_reason == reason) { - netdev_dbg(netdev, "Skipping matching reset\n"); + netdev_dbg(netdev, "Skipping matching reset, reason=%d\n", + reason); spin_unlock_irqrestore(&adapter->rwi_lock, flags); ret = EBUSY; goto err;
We sometimes run into situations where a soft/hard reset of the adapter takes a long time or fails to complete. Having additional messages that include important adapter state info will hopefully help understand what is happening, reduce the guess work and minimize requests to reproduce problems with debug patches. Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com> --- Changelog[v2] [Jakub Kacinski] Change an netdev_err() to netdev_info()? Changed to netdev_dbg() instead. Also sending to net rather than net-next. Note: this debug patch is based on following bug fixes and a feature from Dany Madden and Lijun Pan: https://lore.kernel.org/netdev/20201123193547.57225-1-ljp@linux.ibm.com/ https://lore.kernel.org/netdev/319f8afadcd856037b1d83891f98db3d@linux.vnet.ibm.com/ https://lore.kernel.org/netdev/20201123235841.6515-1-drt@linux.ibm.com/ --- drivers/net/ethernet/ibm/ibmvnic.c | 25 ++++++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-)