All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kai-Heng Feng <kaihengfeng@me.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [1/5] xhci: Fix perceived dead host due to runtime suspend race with event handler
Date: Thu, 12 Jul 2018 11:30:46 +0800	[thread overview]
Message-ID: <9995D389-A7EF-41FA-AAE4-70ADBD8CFAC9@me.com> (raw)
In-Reply-To: <1529587185-2776-2-git-send-email-mathias.nyman@linux.intel.com>

Hi Mathias,

at 21:19, Mathias Nyman <mathias.nyman@linux.intel.com> wrote:

> Don't rely on event interrupt (EINT) bit alone to detect pending port
> change in resume. If no change event is detected the host may be suspended
> again, oterwise roothubs are resumed.
>
> There is a lag in xHC setting EINT. If we don't notice the pending change
> in resume, and the controller is runtime suspeded again, it causes the
> event handler to assume host is dead as it will fail to read xHC registers
> once PCI puts the controller to D3 state.
>
> [  268.520969] xhci_hcd: xhci_resume: starting port polling.
> [  268.520985] xhci_hcd: xhci_hub_status_data: stopping port polling.
> [  268.521030] xhci_hcd: xhci_suspend: stopping port polling.
> [  268.521040] xhci_hcd: // Setting command ring address to 0x349bd001
> [  268.521139] xhci_hcd: Port Status Change Event for port 3
> [  268.521149] xhci_hcd: resume root hub
> [  268.521163] xhci_hcd: port resume event for port 3
> [  268.521168] xhci_hcd: xHC is not running.
> [  268.521174] xhci_hcd: handle_port_status: starting port polling.
> [  268.596322] xhci_hcd: xhci_hc_died: xHCI host controller not  
> responding, assume dead
>
> The EINT lag is described in a additional note in xhci specs 4.19.2:
>
> "Due to internal xHC scheduling and system delays, there will be a lag
> between a change bit being set and the Port Status Change Event that it
> generated being written to the Event Ring. If SW reads the PORTSC and
> sees a change bit set, there is no guarantee that the corresponding Port
> Status Change Event has already been written into the Event Ring."
>
> Cc: <stable@vger.kernel.org>


I tried to backport this patch to v4.15, and "xhci: Create new structures  
to store xhci port information" series is a dependency for this patch.

The series brings substantial changes, so I am wondering if you have any  
plan to backport this patch to older kernels?

Kai-Heng


> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>

WARNING: multiple messages have this Message-ID (diff)
From: Kai-Heng Feng <kaihengfeng@me.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	stable@vger.kernel.org
Subject: [1/5] xhci: Fix perceived dead host due to runtime suspend race with event handler
Date: Thu, 12 Jul 2018 11:30:46 +0800	[thread overview]
Message-ID: <9995D389-A7EF-41FA-AAE4-70ADBD8CFAC9@me.com> (raw)

Hi Mathias,

at 21:19, Mathias Nyman <mathias.nyman@linux.intel.com> wrote:

> Don't rely on event interrupt (EINT) bit alone to detect pending port
> change in resume. If no change event is detected the host may be suspended
> again, oterwise roothubs are resumed.
>
> There is a lag in xHC setting EINT. If we don't notice the pending change
> in resume, and the controller is runtime suspeded again, it causes the
> event handler to assume host is dead as it will fail to read xHC registers
> once PCI puts the controller to D3 state.
>
> [  268.520969] xhci_hcd: xhci_resume: starting port polling.
> [  268.520985] xhci_hcd: xhci_hub_status_data: stopping port polling.
> [  268.521030] xhci_hcd: xhci_suspend: stopping port polling.
> [  268.521040] xhci_hcd: // Setting command ring address to 0x349bd001
> [  268.521139] xhci_hcd: Port Status Change Event for port 3
> [  268.521149] xhci_hcd: resume root hub
> [  268.521163] xhci_hcd: port resume event for port 3
> [  268.521168] xhci_hcd: xHC is not running.
> [  268.521174] xhci_hcd: handle_port_status: starting port polling.
> [  268.596322] xhci_hcd: xhci_hc_died: xHCI host controller not  
> responding, assume dead
>
> The EINT lag is described in a additional note in xhci specs 4.19.2:
>
> "Due to internal xHC scheduling and system delays, there will be a lag
> between a change bit being set and the Port Status Change Event that it
> generated being written to the Event Ring. If SW reads the PORTSC and
> sees a change bit set, there is no guarantee that the corresponding Port
> Status Change Event has already been written into the Event Ring."
>
> Cc: <stable@vger.kernel.org>


I tried to backport this patch to v4.15, and "xhci: Create new structures  
to store xhci port information" series is a dependency for this patch.

The series brings substantial changes, so I am wondering if you have any  
plan to backport this patch to older kernels?

Kai-Heng


> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2018-07-12  4:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1529587185-2776-1-git-send-email-mathias.nyman@linux.intel.com>
2018-06-21 13:19 ` [PATCH 1/5] xhci: Fix perceived dead host due to runtime suspend race with event handler Mathias Nyman
2018-06-21 13:19   ` [1/5] " Mathias Nyman
2018-07-12  3:30   ` Kai-Heng Feng [this message]
2018-07-12  3:30     ` Kai-Heng Feng
2018-06-21 13:19 ` [PATCH 2/5] xhci: Fix kernel oops in trace_xhci_free_virt_device Mathias Nyman
2018-06-21 13:19   ` [2/5] " Mathias Nyman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9995D389-A7EF-41FA-AAE4-70ADBD8CFAC9@me.com \
    --to=kaihengfeng@me.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.