On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork [off-list ref] wrote:
quoted
Oliver Neukum [off-list ref] writes:
quoted
On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
quoted
These problems could very well be caused by running at SuperSpeed
(USB-3) instead of high speed (USB-2).
Yes, it's running at SuperSpeed, on a Kabylake laptop.
It does not have this issue on a Broadwell laptop, also running at SuperSpeed.
Then I must join Oliver, being very surprised by where in the stack you
attempt to fix the issue. What you write above indicates a problem in
pci bridge or usb host controller, doesn't it?
Bjørn
From: Oliver Neukum <oneukum@suse.com> Date: 2016-11-10 11:28:29
On Thu, 2016-11-10 at 12:09 +0100, Bjørn Mork wrote:
Kai-Heng Feng [off-list ref] writes:
quoted
On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork [off-list ref] wrote:
quoted
Oliver Neukum [off-list ref] writes:
quoted
On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
quoted
These problems could very well be caused by running at SuperSpeed
(USB-3) instead of high speed (USB-2).
Yes, it's running at SuperSpeed, on a Kabylake laptop.
It does not have this issue on a Broadwell laptop, also running at SuperSpeed.
Then I must join Oliver, being very surprised by where in the stack you
attempt to fix the issue. What you write above indicates a problem in
pci bridge or usb host controller, doesn't it?
Indeed. And this means we need an XHCI specialist.
Mathias, we have a failure specific to one implementation of XHCI.
Regards
Oliver
On Thu, 2016-11-10 at 12:09 +0100, Bjørn Mork wrote:
quoted
Kai-Heng Feng [off-list ref] writes:
quoted
On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork [off-list ref] wrote:
quoted
Oliver Neukum [off-list ref] writes:
quoted
On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
quoted
These problems could very well be caused by running at SuperSpeed
(USB-3) instead of high speed (USB-2).
Yes, it's running at SuperSpeed, on a Kabylake laptop.
It does not have this issue on a Broadwell laptop, also running at SuperSpeed.
Then I must join Oliver, being very surprised by where in the stack you
attempt to fix the issue. What you write above indicates a problem in
pci bridge or usb host controller, doesn't it?
Indeed. And this means we need an XHCI specialist.
Mathias, we have a failure specific to one implementation of XHCI.
Could be related to resume singnalling time.
Does the xhci fix for it in 4.9-rc3 help?
commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514
xhci: use default USB_RESUME_TIMEOUT when resuming ports.
It doesn't directly explain why it would work on Broadwell but not Kabylake,
but it resolved very similar cases.
If not, then adding dynamic debug for xhci could show something.
-Mathias
On Fri, Nov 11, 2016 at 10:44 PM, Mathias Nyman
[off-list ref] wrote:
On 10.11.2016 13:22, Oliver Neukum wrote:
quoted
On Thu, 2016-11-10 at 12:09 +0100, Bjørn Mork wrote:
quoted
Kai-Heng Feng [off-list ref] writes:
quoted
On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork [off-list ref] wrote:
quoted
Oliver Neukum [off-list ref] writes:
quoted
On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
quoted
These problems could very well be caused by running at SuperSpeed
(USB-3) instead of high speed (USB-2).
Yes, it's running at SuperSpeed, on a Kabylake laptop.
It does not have this issue on a Broadwell laptop, also running at
SuperSpeed.
Then I must join Oliver, being very surprised by where in the stack you
attempt to fix the issue. What you write above indicates a problem in
pci bridge or usb host controller, doesn't it?
Yes, I was totally wrong about that.
quoted
Indeed. And this means we need an XHCI specialist.
Mathias, we have a failure specific to one implementation of XHCI.
Could be related to resume singnalling time.
Does the xhci fix for it in 4.9-rc3 help?
commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514
xhci: use default USB_RESUME_TIMEOUT when resuming ports.
It doesn't directly explain why it would work on Broadwell but not Kabylake,
but it resolved very similar cases.
If not, then adding dynamic debug for xhci could show something.
I tried the latest commit, 6005a545cadb2adca64350c7aee17d002563e8c7,
on for-usb-next branch.
Now the cdc_mbim still probe failed at the first time, but somehow it
re-probed again with a success.
I reverted commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514 and the
behavior is the same, first time probed failed, second time probed
success.
The attached dmesg is with usbcore and xhci_hcd dynamic debug enabled.
On Mon, Nov 14, 2016 at 3:34 PM, Kai-Heng Feng
[off-list ref] wrote:
On Fri, Nov 11, 2016 at 10:44 PM, Mathias Nyman
[off-list ref] wrote:
quoted
On 10.11.2016 13:22, Oliver Neukum wrote:
quoted
On Thu, 2016-11-10 at 12:09 +0100, Bjørn Mork wrote:
quoted
Kai-Heng Feng [off-list ref] writes:
quoted
On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork [off-list ref] wrote:
quoted
Oliver Neukum [off-list ref] writes:
quoted
On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
quoted
These problems could very well be caused by running at SuperSpeed
(USB-3) instead of high speed (USB-2).
Yes, it's running at SuperSpeed, on a Kabylake laptop.
It does not have this issue on a Broadwell laptop, also running at
SuperSpeed.
Then I must join Oliver, being very surprised by where in the stack you
attempt to fix the issue. What you write above indicates a problem in
pci bridge or usb host controller, doesn't it?
Yes, I was totally wrong about that.
quoted
quoted
Indeed. And this means we need an XHCI specialist.
Mathias, we have a failure specific to one implementation of XHCI.
Could be related to resume singnalling time.
Does the xhci fix for it in 4.9-rc3 help?
commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514
xhci: use default USB_RESUME_TIMEOUT when resuming ports.
It doesn't directly explain why it would work on Broadwell but not Kabylake,
but it resolved very similar cases.
If not, then adding dynamic debug for xhci could show something.
I tried the latest commit, 6005a545cadb2adca64350c7aee17d002563e8c7,
on for-usb-next branch.
Now the cdc_mbim still probe failed at the first time, but somehow it
re-probed again with a success.
I reverted commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514 and the
behavior is the same, first time probed failed, second time probed
success.
The attached dmesg is with usbcore and xhci_hcd dynamic debug enabled.