On 7/23/2017 9:04 AM, Leon Romanovsky wrote: > On Sun, Jul 23, 2017 at 08:28:03AM -0400, Doug Ledford wrote: >> On Sun, 2017-07-23 at 10:41 +0300, Leon Romanovsky wrote: >>> On Sun, Jul 23, 2017 at 10:39:05AM +0300, Leon Romanovsky wrote: >>>> On Tue, May 30, 2017 at 08:46:09AM +0300, Leon Romanovsky wrote: >>>>> On Mon, May 29, 2017 at 05:20:53PM -0700, Dennis Dalessandro >>>>> wrote: >>>>>> From: Tadeusz Struk <tadeusz.struk@xxxxxxxxx> >>>>>> >>>>>> Playing with IP-O-IB interface can trigger a warning message: >>>>>> "ib0: Failed to modify QP to ERROR state" to be logged. >>>>>> This happens when the QP is in IB_QPS_RESET state and the stack >>>>>> is trying to transition it to IB_QPS_ERR state in >>>>>> ipoib_ib_dev_stop(). >>>>>> >>>>>> According to the IB spec, Table 91 - "QP State Transition >>>>>> Properties" >>>>>> it looks like the transition from reset to error is valid: >>>>>> >>>>>> Transition: Any State to Error >>>>>> Required Attributes: None >>>>>> Optional Attributes: None allowed >>>>>> Actions: Queue processing is stopped. Work Requests pending or >>>>>> in >>>>>> process are completed in error, when possible. >>>>>> >>>>>> This patch allows the transition and quiets the message. >>>>>> >>>>>> Reviewed-by: Dennis Dalessandro <dennis.dalessandro@xxxxxxxxx> >>>>>> Signed-off-by: Tadeusz Struk <tadeusz.struk@xxxxxxxxx> >>>>>> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@xxxxxxxxx >>>>>>> >>>>>> --- >>>>> >>>>> Thanks, >>>>> Reviewed-by: Leon Romanovsky <leonro@xxxxxxxxxxxx> >>>> >>>> Doug, >>>> >>>> After digging more with Erez's help, it looks like the sentence "it >>>> looks like the transition from reset to error is valid:" is not >>>> correct. >>>> >>>> According to the InfiniBandTM Architecture Release 1.3, Figure 126 >>>> QP/EE Context >>>> State Diagram - transition to error from reset is not valid. >>>> >>>> The quote from the spec: >>>> "An error can be forced from any state, except Reset, with the >>>> Modify QP/EE Verb." >>>> >>>> I'll send revert patch along with proper fix. >>> >>> Ahh, it wasn't pushed to kernel.org, so no need to revert and you can >>> simply drop it. >> >> It *is* on kernel.org, and has already been pulled by Linus: > > Thanks, I updated the trees and got it. > > Also I prepared revert and patch and will send once it will finish our regression runs. > https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/commit/?h=rdma-rc&id=b287b76e89503ef1d403cc5cc8bd74b035d25bfa > https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/commit/?h=rdma-rc&id=5dc78ad1904db597bdb4427f3ead437aae86f54c > > BTW, when will you post for-4.14 branch so we will be able to base our > submission queue for the -next? Tomorrow. I wanted to base it on 4.13-rc2 so it would get all of the fixes that went in this week. -- Doug Ledford <dledford@xxxxxxxxxx> GPG Key ID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
Attachment:
signature.asc
Description: OpenPGP digital signature
