[PATCH] usb:xhci:Fix regression when ATI chipsets detected
From: Sandeep Singh
The following commit cause a regression on ATI chipsets.
'commit e788787ef4f9 ("usb:xhci:Add quirk for Certain
failing HP keyboard on reset after resume")'
This causes pinfo->smbus_dev to be wrongly set to NULL on
systems with the ATI chipset that this function checks for first.
Added conditional check for AMD chipsets to avoid the overwriting
pinfo->smbus_dev.
Reported-by: Ben Hutchings
Fixes: e788787ef4f9 ("usb:xhci:Add quirk for Certain
failing HP keyboard on reset after resume")
cc: Nehal Shah
cc:
Signed-off-by: Sandeep Singh
Signed-off-by: Shyam Sundar S K
---
drivers/usb/host/pci-quirks.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 5f4ca78..58b9685 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -142,29 +142,30 @@ static int amd_chipset_sb_type_init(struct
amd_chipset_info *pinfo)
pinfo->sb_type.gen = AMD_CHIPSET_SB700;
else if (rev >= 0x40 && rev <= 0x4f)
pinfo->sb_type.gen = AMD_CHIPSET_SB800;
- }
- pinfo->smbus_dev = pci_get_device(PCI_VENDOR_ID_AMD,
- 0x145c, NULL);
- if (pinfo->smbus_dev) {
- pinfo->sb_type.gen = AMD_CHIPSET_TAISHAN;
} else {
pinfo->smbus_dev = pci_get_device(PCI_VENDOR_ID_AMD,
PCI_DEVICE_ID_AMD_HUDSON2_SMBUS, NULL);
- if (!pinfo->smbus_dev) {
- pinfo->sb_type.gen = NOT_AMD_CHIPSET;
- return 0;
+ if (pinfo->smbus_dev) {
+ rev = pinfo->smbus_dev->revision;
+ if (rev >= 0x11 && rev <= 0x14)
+ pinfo->sb_type.gen = AMD_CHIPSET_HUDSON2;
+ else if (rev >= 0x15 && rev <= 0x18)
+ pinfo->sb_type.gen = AMD_CHIPSET_BOLTON;
+ else if (rev >= 0x39 && rev <= 0x3a)
+ pinfo->sb_type.gen = AMD_CHIPSET_YANGTZE;
+ } else {
+ pinfo->smbus_dev = pci_get_device(PCI_VENDOR_ID_AMD,
+ 0x145c, NULL);
+ if (pinfo->smbus_dev) {
+ rev = pinfo->smbus_dev->revision;
+ pinfo->sb_type.gen = AMD_CHIPSET_TAISHAN;
+ } else {
+ pinfo->sb_type.gen = NOT_AMD_CHIPSET;
+ return 0;
+ }
}
-
- rev = pinfo->smbus_dev->revision;
- if (rev >= 0x11 && rev <= 0x14)
- pinfo->sb_type.gen = AMD_CHIPSET_HUDSON2;
- else if (rev >= 0x15 && rev <= 0x18)
- pinfo->sb_type.gen = AMD_CHIPSET_BOLTON;
- else if (rev >= 0x39 && rev <= 0x3a)
- pinfo->sb_type.gen = AMD_CHIPSET_YANGTZE;
}
-
pinfo->sb_type.rev = rev;
return 1;
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] usb:xhci: update condition to select bus->sysdev from parent device
On Sat, Aug 19, 2017 at 10:43 AM, Thang Q. Nguyen wrote:
> From: "Thang Q. Nguyen"
>
> For commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA
> configuration"), sysdev points to devices known to the system firmware
> or hardware for DMA parameters.
> However, the parent of the system firmware/hardware device checking
> logic does not work in ACPI boot mode. This patch updates the formulation
> to check this case in both DT and ACPI.
>
> Signed-off-by: Tung Nguyen
> Signed-off-by: Thang Q. Nguyen
> ---
> Change since v1:
> - Update codes to work with kernel 4.13-rc5
> ---
> drivers/usb/host/xhci-plat.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index c04144b..1bb9729 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -187,7 +187,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
> * 3. xhci_plat is grandchild of a pci device (dwc3-pci)
> */
> sysdev = &pdev->dev;
> - if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node)
> + if (sysdev->parent && !is_of_node(sysdev->fwnode) &&
> + !is_acpi_device_node(sysdev->fwnode) &&
> + (is_of_node(sysdev->parent->fwnode) ||
> +is_acpi_device_node(sysdev->parent->fwnode)))
> sysdev = sysdev->parent;
> #ifdef CONFIG_PCI
> else if (sysdev->parent && sysdev->parent->parent &&
> --
> 1.8.3.1
>
Is there any comment about the patch?
With current kernel (4.13.0-rc6), booting the Linux using ACPI boot,
kernel is crashed right after probing the USB DWC3 driver with the
following messages:
[ 10.193176] WARNING: CPU: 0 PID: 1 at
drivers/usb/host/xhci-plat.c:199 xhci_plat_probe+0x2f0/0x700
[ 10.193176] WARNING: CPU: 0 PID: 1 at
drivers/usb/host/xhci-plat.c:199 xhci_plat_probe+0x2f0/0x700
[ 10.211272] Modules linked in:
[ 10.211272] Modules linked in:
[ 10.217457] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.13.0-rc6-00066-g143c97c #4
[ 10.217457] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.13.0-rc6-00066-g143c97c #4
[ 10.232727] Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene
Mustang Board, BIOS 3.07.09 Feb 28 2017
[ 10.232727] Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene
Mustang Board, BIOS 3.07.09 Feb 28 2017
[ 10.252464] task: 8001f3c78000 task.stack: 8001f3c74000
[ 10.252464] task: 8001f3c78000 task.stack: 8001f3c74000
[ 10.264383] PC is at xhci_plat_probe+0x2f0/0x700
[ 10.264383] PC is at xhci_plat_probe+0x2f0/0x700
[ 10.273727] LR is at xhci_plat_probe+0x34/0x700
[ 10.273727] LR is at xhci_plat_probe+0x34/0x700
[ 10.282906] pc : [] lr : []
pstate: 0145
[ 10.282906] pc : [] lr : []
pstate: 0145
[ 10.297909] sp : 8001f3c77c00
[ 10.297909] sp : 8001f3c77c00
[ 10.304608] x29: 8001f3c77c00 x28:
[ 10.304608] x29: 8001f3c77c00 x28:
[ 10.315360] x27: 08eac808 x26: 08db0454
[ 10.315360] x27: 08eac808 x26: 08db0454
[ 10.326113] x25: 001c x24:
[ 10.326113] x25: 001c x24:
[ 10.336814] x23: 08fa32d0 x22: 8001f2bd1010
[ 10.336814] x23: 08fa32d0 x22: 8001f2bd1010
[ 10.347532] x21: 8001f2bd1000 x20: 8001f2bd1010
[ 10.347532] x21: 8001f2bd1000 x20: 8001f2bd1010
[ 10.358215] x19: ffed x18:
[ 10.358215] x19: ffed x18:
[ 10.368950] x17: 00030004 x16: 0003
[ 10.368950] x17: 00030004 x16: 0003
[ 10.379642] x15: 8001f3f50400 x14: 0004
[ 10.379642] x15: 8001f3f50400 x14: 0004
[ 10.390403] x13: 0404 x12: 0003
[ 10.390403] x13: 0404 x12: 0003
[ 10.401173] x11: 00030004 x10: 8001f3f50400
[ 10.401173] x11: 00030004 x10: 8001f3f50400
[ 10.411864] x9 : x8 : 001c
[ 10.411864] x9 : x8 : 001c
[ 10.422616] x7 : 8001f3f50400 x6 : 8001f3f50400
[ 10.422616] x7 : 8001f3f50400 x6 : 8001f3f50400
[ 10.433360] x5 : x4 :
[ 10.433360] x5 : x4 :
[ 10.444103] x3 : 08f245b8 x2 : 08f24000
[ 10.444103] x3 : 08f245b8 x2 : 08f24000
[ 10.454864] x1 : x0 :
[ 10.454864] x1 : x0 :
[ 10.465600] Call trace:
[ 10.465600] Call trace:
[ 10.470546] Exception stack(0x8001f3c77a30 to 0x8001f3c77b60)
[ 10.470546] Exception stack(0x8001f3c77a30 to 0x8001f3c77b60)
[ 10.483561] 7a20:
ffed 0001
[ 10.483561] 7a20:
ffed 0001
[
Re: [PATCH] usb: gadget: pch_udc: add checks for dma mapping errors
On Thu, Aug 24, 2017 at 01:47:08AM +0300, Alexey Khoroshilov wrote:
> There are no checks for dma mapping errors in pch_udc.
> Tha patch adds the checks and error handling code.
> Compile tested only.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
> ---
> drivers/usb/gadget/udc/pch_udc.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/pch_udc.c
> b/drivers/usb/gadget/udc/pch_udc.c
> index 84dcbcd756f0..a305f8392082 100644
> --- a/drivers/usb/gadget/udc/pch_udc.c
> +++ b/drivers/usb/gadget/udc/pch_udc.c
> @@ -1767,7 +1767,7 @@ static struct usb_request *pch_udc_alloc_request(struct
> usb_ep *usbep,
> req->req.dma = DMA_ADDR_INVALID;
> req->dma = DMA_ADDR_INVALID;
> INIT_LIST_HEAD(&req->queue);
> - if (!ep->dev->dma_addr)
> + if (ep->dev->dma_addr != DMA_ADDR_INVALID)
> return &req->req;
> /* ep0 in requests are allocated from data pool here */
> dma_desc = dma_pool_alloc(ep->dev->data_requests, gfp,
> @@ -1879,6 +1879,13 @@ static int pch_udc_pcd_queue(struct usb_ep *usbep,
> struct usb_request *usbreq,
> usbreq->length,
> DMA_FROM_DEVICE);
> }
> + if (dma_mapping_error(&dev->pdev->dev, req->dma)) {
> + req->dma = DMA_ADDR_INVALID;
> + retval = -ENOMEM;
> + if ((unsigned long)(usbreq->buf) & 0x03)
> + kfree(req->buf);
> + goto probe_end;
> + }
> req->dma_mapped = 1;
> }
> if (usbreq->length > 0) {
> @@ -2961,6 +2968,10 @@ static int init_dma_pools(struct pch_udc_dev *dev)
> dev->dma_addr = dma_map_single(&dev->pdev->dev, ep0out_buf,
> UDC_EP0OUT_BUFF_SIZE * 4,
> DMA_FROM_DEVICE);
> + if (dma_mapping_error(&dev->pdev->dev, dev->dma_addr)) {
> + dev->dma_addr = DMA_ADDR_INVALID;
> + return -ENOMEM;
> + }
Wouldn't this driver be better off using the
usb_gadget_{map,unmap}_request() functions provided by UDC core.c?
dma_mapping_error() is provided for free that way.
Jack
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb:xhci:Fix regression when ATI chipsets detected
On Wed, Aug 23, 2017 at 04:26:00PM +0530, Sandeep Singh wrote:
> From: Sandeep Singh
>
> The following commit cause a regression on ATI chipsets.
> 'commit e788787ef4f9 ("usb:xhci:Add quirk for Certain
> failing HP keyboard on reset after resume")'
>
> This causes pinfo->smbus_dev to be wrongly set to NULL on
> systems with the ATI chipset that this function checks for first.
>
> Added conditional check for AMD chipsets to avoid the overwriting
> pinfo->smbus_dev.
>
> Reported-by: Ben Hutchings
> Signed-off-by: Sandeep Singh
> Signed-off-by: Shyam Sundar S K
> cc: Nehal Shah
A "Fixes:" tag here would be good, as would a "cc:
sta...@vger.kernel.org" right?
And you have tested this out well, right?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: pch_udc: add checks for dma mapping errors
There are no checks for dma mapping errors in pch_udc.
Tha patch adds the checks and error handling code.
Compile tested only.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/usb/gadget/udc/pch_udc.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc/pch_udc.c b/drivers/usb/gadget/udc/pch_udc.c
index 84dcbcd756f0..a305f8392082 100644
--- a/drivers/usb/gadget/udc/pch_udc.c
+++ b/drivers/usb/gadget/udc/pch_udc.c
@@ -1767,7 +1767,7 @@ static struct usb_request *pch_udc_alloc_request(struct
usb_ep *usbep,
req->req.dma = DMA_ADDR_INVALID;
req->dma = DMA_ADDR_INVALID;
INIT_LIST_HEAD(&req->queue);
- if (!ep->dev->dma_addr)
+ if (ep->dev->dma_addr != DMA_ADDR_INVALID)
return &req->req;
/* ep0 in requests are allocated from data pool here */
dma_desc = dma_pool_alloc(ep->dev->data_requests, gfp,
@@ -1879,6 +1879,13 @@ static int pch_udc_pcd_queue(struct usb_ep *usbep,
struct usb_request *usbreq,
usbreq->length,
DMA_FROM_DEVICE);
}
+ if (dma_mapping_error(&dev->pdev->dev, req->dma)) {
+ req->dma = DMA_ADDR_INVALID;
+ retval = -ENOMEM;
+ if ((unsigned long)(usbreq->buf) & 0x03)
+ kfree(req->buf);
+ goto probe_end;
+ }
req->dma_mapped = 1;
}
if (usbreq->length > 0) {
@@ -2961,6 +2968,10 @@ static int init_dma_pools(struct pch_udc_dev *dev)
dev->dma_addr = dma_map_single(&dev->pdev->dev, ep0out_buf,
UDC_EP0OUT_BUFF_SIZE * 4,
DMA_FROM_DEVICE);
+ if (dma_mapping_error(&dev->pdev->dev, dev->dma_addr)) {
+ dev->dma_addr = DMA_ADDR_INVALID;
+ return -ENOMEM;
+ }
return 0;
}
@@ -3038,7 +3049,7 @@ static void pch_udc_remove(struct pci_dev *pdev)
dma_pool_destroy(dev->stp_requests);
}
- if (dev->dma_addr)
+ if (dev->dma_addr != DMA_ADDR_INVALID)
dma_unmap_single(&dev->pdev->dev, dev->dma_addr,
UDC_EP0OUT_BUFF_SIZE * 4, DMA_FROM_DEVICE);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: high irqs-off latency caused by USB serial driver
On Wed, 23 Aug 2017, David Mosberger wrote: > Alan, > > On Wed, Aug 23, 2017 at 10:30 AM, Alan Stern > wrote: > > >> Does anybody know why HCD_BH is not enabled in ohci-hcd.c? > > > > Because it changes the semantics of isochronous and interrupt > > streaming. See for example commits 9118f9eb4f1e, 24f531371de1, and > > 46c73d1d3ebc. > > Cool, this is very helpful. So if one doesn't care about isochronous > transfers, worst case > would be that interrupt transfers might be handled less efficiently > than they should be, > but other than that, OHCI would work fine with HCD_BH? Basically, yes. > I did just try turning on the flag in ohci-hcd.c and it makes a > significant difference: > during a 1-minute test run, it reduces the number of missed deadlines in my > soft-realtime task from 757 to 49! Have you tried using the RT patch set? It may or may not be practical for you, but it could end up making an even larger difference. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: high irqs-off latency caused by USB serial driver
On Wed, 23 Aug 2017, David Mosberger wrote: > Actually, I just found this commit: > > 94dfd7edf USB: HCD: support giveback of URB in tasklet context > > It won't fix the problem entirely, but I think it should cut the worst-case > irqs-disabled latency about in half, which would be a good improvement. > > Does anybody know why HCD_BH is not enabled in ohci-hcd.c? Because it changes the semantics of isochronous and interrupt streaming. See for example commits 9118f9eb4f1e, 24f531371de1, and 46c73d1d3ebc. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: high irqs-off latency caused by USB serial driver
On Wed, 23 Aug 2017, David Mosberger wrote:
> On Tue, Aug 22, 2017 at 3:40 PM, Greg KH wrote:
> > On Tue, Aug 22, 2017 at 02:44:20PM -0600, David Mosberger wrote:
>
> >> > There was an option a while ago to turn USB irqs
> >> > into threaded irqs, do those work on your platform? If so, that might
> >> > help you out here.
> >>
> >> Do you mean this:
> >>
> >>https://lkml.org/lkml/2008/10/20/465
> >>
> >> or is there something else/newer?
> >
> > I think there was something newer than that almost-a-decade-old thread,
> > but I don't remember. Look at what the RT kernel patch does, it might
> > be in there if it wasn't merged into the tree already.
>
> Actually, I'm not able to find much in this direction.
> Do you have something more specific I could be looking for?
>
> I don't think the RT patches would (readily) work for my case as I have
> a (soft-)realtime interrupt handler that depends on other drivers (e.g,.
> SPI and DMA).
>
> Looking at the OHCI and EHCI drivers more carefully, even if those
> were turned into threaded handlers, the problem would not
> (automatically) go away since they implicitly (OHCI) or explicitly (EHCI)
> disable (local) interrupt delivery while processing the URBs (in particular,
> while giving them back, which can trigger a lot of extra work).
I was going to point out something along these lines. Even if the
majority of the work gets done in a threaded handler, that doesn't help
much if the threaded handler runs with interrupts disabled.
However, your understanding is not entirely correct. When ehci-hcd
gives back an URB, the USB core handles it in a tasklet -- not in the
context used by ehci-hcd. The tasklet runs with interrupts enabled for
at least part of the time. (In theory it could run with interrupts
enabled almost all of the time, but it was not deemed practical to do
this because USB drivers were originally written with the understanding
that their URB-completion handlers would be called with interrupts
disabled, and auditing all of them was too difficult.)
The same is not true for ohci-hcd, but in principle the driver could be
changed to act the same as ehci-hcd. This was not considered a high
priority because ohci-hcd only handles USB-1.1 connections, which are
considerably slower than USB-2.
> I'd very much appreciate any pointers to any work or thought that
> might have gone into improving this situation (in particular: returning
> URBs with interrupts enabled). The USB stack disabling
> interrupts for such extended periods of time surely isn't a problem just
> in my situation.
As far as I know, nobody has complained about it before you.
See commit 94dfd7edfd5c ("USB: HCD: support giveback of URB in tasklet
context"). Implementing this in ehci-hcd required some non-trivial
changes.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: high irqs-off latency caused by USB serial driver
Actually, I just found this commit: 94dfd7edf USB: HCD: support giveback of URB in tasklet context It won't fix the problem entirely, but I think it should cut the worst-case irqs-disabled latency about in half, which would be a good improvement. Does anybody know why HCD_BH is not enabled in ohci-hcd.c? --david -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: reducing an usb-port auto-resume latency.
On 23.08.2017 17:30, Alan Stern wrote: On Wed, 23 Aug 2017, Mathias Nyman wrote: On 23.08.2017 09:18, anshuman.gu...@intel.com wrote: From: Anshuman Gupta This patch will improve the variable auto-resume latency of an usb-port. When xhci gets a port status change event interrupt due to PORT_PLC (port link state transition), linux Host controller driver drives the resume signalling on the bus for the amount of time defined by USB_REUME_TIMEOUT(40ms) macro. This 40ms delay for resume signalling is in acceptable limit, but it get worse when xhci goes for polling mode in order to detect other events on its ports and modify rh_timer timer with a variable time out of 1ms to (HZ/4)ms. drivers/usb/core/hcd.c line 799 mod_timer (&hcd->rh_timer, (jiffies/(HZ/4) + 1) * (HZ/4)). Due to above variable timeout usb auto-resume latency varies from 40ms to ~300ms. Log Snippet: ~128ms latency [ 53.112049] hub 1-0:1.0: state 7 ports 12 chg evt [ 53.229200] hub 1-0:1.0: state 7 ports 12 chg evt 0004 [ 53.240177] usb 1-2: usb wakeup-resume [ 53.240195] usb 1-2: finish resume [ 53.240357] usb usb1-port2: resume, status 0 - ~300ms latency [ 59.946620] hub 1-0:1.0: state 7 ports 12 chg evt [ 59.979341] hub 1-0:1.0: state 7 ports 12 chg evt [ 60.229342] hub 1-0:1.0: state 7 ports 12 chg evt 0004 [ 60.251321] usb 1-2: usb wakeup-resume [ 60.251335] usb 1-2: finish resume [ 60.251539] usb usb1-port2: resume, status 0 This variable resume latency can be optimized, as in case of PORT_PLC change event rh_timer has already been modified with USB_RESUME_TIMEOUT (40ms) delay,leaving the rest to GetPortStatus and started polling for root hub status (invoking usb_hcd_poll_rh_status). We can avoid polling as we have already modified rh_timer with delay of 40ms. This patch set the HCD_FLAG_POLL_RH to hcd->flags after modification of rh_timer, and avoids polling of root hub status. so rh_timer can fire after 40ms and usb device auto-resuem latency will be around 40ms. Signed-off-by: Anshuman Gupta --- Thanks, adding and sending forward after 4.14-rc1 This patch description doesn't make sense. If you want to avoid resetting the root-hub timer by 250 ms, you should _clear_ the HCD_FLAG_POLL_RH flag, not _set_ it! See this (slightly tricky) code in usb_hcd_poll_rh_status(): if (hcd->uses_new_polling ? HCD_POLL_RH(hcd) : (length == 0 && hcd->status_urb != NULL)) mod_timer (&hcd->rh_timer, (jiffies/(HZ/4) + 1) * (HZ/4)); Since xhci-hcd does set the uses_new_polling flag, the "if" condition just tests the HCD_FLAG_POLL_RH bit. The description could be a bit clearer, I agree, but the issue it fixes seems correct. We want start the rh polling when a HS port is found in resume state, and we want to time it so that the it runs just after resume is complete (40ms) This is why we have the mod_timer(&hcd->rh_timer, bus_state->resume_done[faked_port_index]); This would all be fine, but the xhci event handler has a bug and it calls usb_hcd_poll_rh_status(hcd) manually right after modifying rh_timer. This causes hub thread to read port status before resume is ready, and we need to wait for another 250ms before the rh thread can handle the port. What this patch in the end does is just removing the manual usb_hcd_poll_rh_status(hcd) in this case. Thanks -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: high irqs-off latency caused by USB serial driver
On Tue, Aug 22, 2017 at 3:40 PM, Greg KH wrote: > On Tue, Aug 22, 2017 at 02:44:20PM -0600, David Mosberger wrote: >> > There was an option a while ago to turn USB irqs >> > into threaded irqs, do those work on your platform? If so, that might >> > help you out here. >> >> Do you mean this: >> >>https://lkml.org/lkml/2008/10/20/465 >> >> or is there something else/newer? > > I think there was something newer than that almost-a-decade-old thread, > but I don't remember. Look at what the RT kernel patch does, it might > be in there if it wasn't merged into the tree already. Actually, I'm not able to find much in this direction. Do you have something more specific I could be looking for? I don't think the RT patches would (readily) work for my case as I have a (soft-)realtime interrupt handler that depends on other drivers (e.g,. SPI and DMA). Looking at the OHCI and EHCI drivers more carefully, even if those were turned into threaded handlers, the problem would not (automatically) go away since they implicitly (OHCI) or explicitly (EHCI) disable (local) interrupt delivery while processing the URBs (in particular, while giving them back, which can trigger a lot of extra work). I'd very much appreciate any pointers to any work or thought that might have gone into improving this situation (in particular: returning URBs with interrupts enabled). The USB stack disabling interrupts for such extended periods of time surely isn't a problem just in my situation. --david -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Web camera USB bandwidth allocation
On Wed, 23 Aug 2017, Martin Oprešnik wrote:
> Hi,
>
> What happens when you try to use the fourth camera?
>
> I'm sorry I forgot to write whet the actual problem is. Error message is
> "No space left on device". Based on what I read this means there it
> can't allocate enough bandwidth.
>
> Using this command (cat /sys/kernel/debug/usb/devices | grep "B: "), I
> could see bandwidth allocation if cameras are connected to USB 2.0, but
> not if connected to 3.0 port. With this command and usbtop I created
> this table.
>
> +-+--+--++
> | Resolution | Name | Bandwidth allocation | Transfer rate |
> +-+--+--++
> | 1280x720| 720p | 256us| up to ~1.4Mb/s |
> | 1600x896| | 424us| up to ~1.7Mb/s |
> | 1920x1080 | Full HD | 488us| up to ~1.8Mb/s |
> +-+--+--++
>
> On USB 2.0 port there is 800us available bandwidth, that means i could
> run cameras in this modes:
> -3 cameras in 720p (used 96% of bandwidth)
> -one camera in 720p and one camera in FullHD
>
> On USB 3.0 port I can run cameras in same formats as on USB 2.0 and
> additionally
> -one camera in FullHD and one camera in 1600x896
>
> I currently don't have 4 cameras, but I suppose that if we can make
> cameras to work on higher resolutions, I could add more cameras.
> Cameras are connected trough TP-LINK 3.0 USB hub (Model: UH720), but
> there is no difference if I connect one camera directly and other over hub.
Your bandwidth calculations do not take into account the USB keyboard
and the OM device (whatever that is). They use up a significant
fraction of the total bandwidth.
Try plugging those two devices into USB-2 ports (or into a hub that
is plugged into a USB-2 port) while plugging the cameras all into USB-3
ports (or into a hub that is plugged into a USB-3 port), and see if
that helps at all.
And try to avoid nesting hubs deeply; you're better off plugging
multiple hubs each into a separate controller than all of them through
a single hub into a single controller.
Alan Stern
> Then while running with 3 cameras, make a copy of
> /sys/kernel/debug/usb/devices and post the copy.
>
> I added attachment.
>
> Also, what version of the kernel are you using?
>
> Linux odroid 4.9.38
>
> and which host controller? (xhci, ehci, ohci, uhci)
>
> Using this code:
> struct v4l2_capability caps = {};
> if (-1 == xioctl(fd, VIDIOC_QUERYCAP, &caps))
> {
> perror("Querying Capabilities");
> return 1;
> }
>
> printf( "Driver Caps:\n"
> " Driver: \"%s\"\n"
> " Card: \"%s\"\n"
> " Bus: \"%s\"\n"
> " Version: %d.%d\n"
> " Capabilities: %08x\n",
> caps.driver,
> caps.card,
> caps.bus_info,
> (caps.version>>16)&&0xff,
> (caps.version>>24)&&0xff,
> caps.capabilities);
> It says "usb-xhci-hcd.2.auto-1.1.1.4".
>
> On 23. 08. 2017 08:04, Felipe Balbi wrote:
> > Hi,
> >
> > Alan Stern writes:
> >> On Tue, 22 Aug 2017, Martin Oprešnik wrote:
> >>
> >>> Hello,
> >>>
> >>> we are working on a project, where we need multiple cameras connected to
> >>> embedded computer. For computer we have chosen odroid XU4 and for
> >>> cameras Logitech C920. We need at least 5 cameras running with 720p. The
> >>> problem we have is allocated USB bandwidth (cameras are using
> >>> isochronous transfer). Currently we can run 3 cameras on 720p. Image is
> >>> transferred in h264 compressed format. Writing on disk is done directly
> >>> trough memory map using V4L2 api and files on disk are really small and
> >>> using usbmon/wireshark shows ~1104kB/s (there should be a lot of USB
> >>> bandwidth left).
> >> What happens when you try to use the fourth camera?
> >>
> >>> I tried same setups on my laptop and I don't get any better results, so
> >>> I suspect there is some space for improvement in software and it's not
> >>> odroid's fault. I tried changing different parameters in uvcvideo driver
> >>> and I think only wMaxPacketSize is affecting bandwidth allocation. And
> >>> changing that is reflected in non working camera.
> >>> Now I don't know enough about USB and linux kernel to work around this
> >>> problem and I would be very happy if you could give me some help or
> >>> directions.
> >>> If I should provide some additional information, I'll be happy to add it.
> >>>
> >>> I am looking forward to hearing from you.
> >> Please try the following. First, mount a debugfs filesystem:
> >>
> >>mount -t debugfs none /sys/kernel/debug
> >>
> >> Then while running with 3 cameras, make a copy of
> >> /sys/kernel/debug/usb/devices and post the copy.
> >>
>
Re: [PATCH] usb: reducing an usb-port auto-resume latency.
On Wed, 23 Aug 2017, Mathias Nyman wrote: > On 23.08.2017 09:18, anshuman.gu...@intel.com wrote: > > From: Anshuman Gupta > > > > This patch will improve the variable auto-resume latency of an usb-port. > > > > When xhci gets a port status change event interrupt due to PORT_PLC > > (port link state transition), linux Host controller driver drives the > > resume signalling on the bus for the amount of time defined by > > USB_REUME_TIMEOUT(40ms) macro. > > > > This 40ms delay for resume signalling is in acceptable limit, but > > it get worse when xhci goes for polling mode in order to detect other > > events on its ports and modify rh_timer timer with a variable time out of > > 1ms to (HZ/4)ms. > > > > drivers/usb/core/hcd.c line 799 > > mod_timer (&hcd->rh_timer, (jiffies/(HZ/4) + 1) * (HZ/4)). > > > > Due to above variable timeout usb auto-resume latency varies from > > 40ms to ~300ms. > > > > Log Snippet: > > ~128ms latency > > [ 53.112049] hub 1-0:1.0: state 7 ports 12 chg evt > > [ 53.229200] hub 1-0:1.0: state 7 ports 12 chg evt 0004 > > [ 53.240177] usb 1-2: usb wakeup-resume > > [ 53.240195] usb 1-2: finish resume > > [ 53.240357] usb usb1-port2: resume, status 0 > > - > > ~300ms latency > > [ 59.946620] hub 1-0:1.0: state 7 ports 12 chg evt > > [ 59.979341] hub 1-0:1.0: state 7 ports 12 chg evt > > [ 60.229342] hub 1-0:1.0: state 7 ports 12 chg evt 0004 > > [ 60.251321] usb 1-2: usb wakeup-resume > > [ 60.251335] usb 1-2: finish resume > > [ 60.251539] usb usb1-port2: resume, status 0 > > > > This variable resume latency can be optimized, as in case of PORT_PLC > > change event rh_timer has already been modified with USB_RESUME_TIMEOUT > > (40ms) delay,leaving the rest to GetPortStatus and started polling for > > root hub status (invoking usb_hcd_poll_rh_status). > > We can avoid polling as we have already modified rh_timer with > > delay of 40ms. > > > > This patch set the HCD_FLAG_POLL_RH to hcd->flags after modification of > > rh_timer, and avoids polling of root hub status. so rh_timer can fire > > after 40ms and usb device auto-resuem latency will be around 40ms. > > > > Signed-off-by: Anshuman Gupta > > --- > > Thanks, > adding and sending forward after 4.14-rc1 This patch description doesn't make sense. If you want to avoid resetting the root-hub timer by 250 ms, you should _clear_ the HCD_FLAG_POLL_RH flag, not _set_ it! See this (slightly tricky) code in usb_hcd_poll_rh_status(): if (hcd->uses_new_polling ? HCD_POLL_RH(hcd) : (length == 0 && hcd->status_urb != NULL)) mod_timer (&hcd->rh_timer, (jiffies/(HZ/4) + 1) * (HZ/4)); Since xhci-hcd does set the uses_new_polling flag, the "if" condition just tests the HCD_FLAG_POLL_RH bit. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression between 4.9 and 4.13
On 23/08/2017 14:41, Mason wrote: > I compiled a minimal kernel, with lots of irrelevant drivers and > frameworks left out, including power management. I still get the > "xHCI host controller not responding, assume dead" issue. The problem seems to have a timing-related aspect. I added a bunch of logs (to a slow serial console) and the HC was not killed. I was able to plug the Flash drive a second time. (I am logging config space reads and writes.) [1.098314] READ: bus=1 devfn=0 where=84 size=2 val=0x8 [1.103779] READ: bus=1 devfn=0 where=4 size=2 val=0x142 [1.109315] READ: bus=1 devfn=0 where=61 size=1 val=0x1 [1.114746] READ: bus=1 devfn=0 where=4 size=2 val=0x142 [1.120311] READ: bus=1 devfn=0 where=4 size=2 val=0x142 [1.125841] WRITE: bus=1 devfn=0 where=4 size=2 val=0x146 NB: I added msleep(2500) in usb_add_hcd() [3.681867] xhci_hcd :01:00.0: xHCI Host Controller [3.687154] xhci_hcd :01:00.0: new USB bus registered, assigned bus number 1 [3.694656] READ: bus=1 devfn=0 where=96 size=1 val=0x30 [3.705736] xhci_hcd :01:00.0: hcc params 0x014051cf hci version 0x100 quirks 0x0010 [3.714233] READ: bus=1 devfn=0 where=12 size=1 val=0x10 [3.719752] READ: bus=1 devfn=0 where=4 size=2 val=0x146 [3.725269] WRITE: bus=1 devfn=0 where=4 size=2 val=0x156 [3.730794] READ: bus=1 devfn=0 where=146 size=2 val=0x7 [3.736314] READ: bus=1 devfn=0 where=146 size=2 val=0x7 [3.741835] WRITE: bus=1 devfn=0 where=146 size=2 val=0x7 [3.747354] READ: bus=1 devfn=0 where=146 size=2 val=0x7 [3.752871] READ: bus=1 devfn=0 where=148 size=4 val=0x1000 [3.758775] READ: bus=1 devfn=0 where=146 size=2 val=0x7 [3.764297] WRITE: bus=1 devfn=0 where=146 size=2 val=0xc007 [3.770108] READ: bus=1 devfn=0 where=4 size=2 val=0x146 [3.775626] WRITE: bus=1 devfn=0 where=4 size=2 val=0x546 [3.781146] READ: bus=1 devfn=0 where=146 size=2 val=0xc007 [3.786925] WRITE: bus=1 devfn=0 where=146 size=2 val=0x8007 [3.792919] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [3.799756] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [3.807021] usb usb1: Product: xHCI Host Controller [3.811933] usb usb1: Manufacturer: Linux 4.12.0-rc1 xhci-hcd [3.817713] usb usb1: SerialNumber: :01:00.0 [3.822773] hub 1-0:1.0: USB hub found [3.826598] hub 1-0:1.0: 4 ports detected NB: I added msleep(2500) in usb_add_hcd() [6.455246] xhci_hcd :01:00.0: xHCI Host Controller [6.460520] xhci_hcd :01:00.0: new USB bus registered, assigned bus number 2 [6.468028] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM. [6.476236] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003 [6.483068] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [6.490334] usb usb2: Product: xHCI Host Controller [6.495240] usb usb2: Manufacturer: Linux 4.12.0-rc1 xhci-hcd [6.501020] usb usb2: SerialNumber: :01:00.0 [6.505994] hub 2-0:1.0: USB hub found [6.509806] hub 2-0:1.0: 4 ports detected [6.514215] usbcore: registered new interface driver usb-storage [6.520313] Registering SWP/SWPB emulation handler [6.525541] READ: bus=0 devfn=0 where=132 size=4 val=0x8001 [6.531334] READ: bus=0 devfn=0 where=6 size=2 val=0x4010 [6.536955] READ: bus=0 devfn=0 where=52 size=1 val=0x50 [6.542484] READ: bus=0 devfn=0 where=80 size=2 val=0x7805 [6.548180] READ: bus=0 devfn=0 where=120 size=2 val=0x8001 [6.553969] READ: bus=0 devfn=0 where=128 size=2 val=0x10 [6.559584] READ: bus=0 devfn=0 where=124 size=2 val=0x6008 [6.565387] READ: bus=1 devfn=0 where=164 size=4 val=0x8fc0 [6.571167] READ: bus=1 devfn=0 where=6 size=2 val=0x10 [6.576609] READ: bus=1 devfn=0 where=52 size=1 val=0x50 [6.582129] READ: bus=1 devfn=0 where=80 size=2 val=0x7001 [6.587821] READ: bus=1 devfn=0 where=112 size=2 val=0x9005 [6.593601] READ: bus=1 devfn=0 where=144 size=2 val=0xa011 [6.599381] READ: bus=1 devfn=0 where=160 size=2 val=0x10 [6.604985] READ: bus=1 devfn=0 where=84 size=2 val=0x8 [6.623665] Freeing unused kernel memory: 9216K PLUG #1 [ 66.783559] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd [ 66.816910] usb 2-2: New USB device found, idVendor=0951, idProduct=1666 [ 66.823661] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 66.830909] usb 2-2: Product: DataTraveler 3.0 [ 66.835417] usb 2-2: Manufacturer: Kingston [ 66.839660] usb 2-2: SerialNumber: 002618887865F0C0F8646BFA [ 66.848131] usb-storage 2-2:1.0: USB Mass Storage device detected [ 66.854584] scsi host0: usb-storage 2-2:1.0 [ 67.869446] scsi 0:0:0:0: Direct-Access Kingston DataTraveler 3.0 PQ: 0 ANSI: 6 [ 67.878270] sd 0:0:0:0: [sda] 15109516 512-byte logical blocks: (7.74 GB/7.20 GiB) [
Re: Possible regression between 4.9 and 4.13
On 23/08/2017 13:54, Mason wrote: > On 23/08/2017 13:11, Mathias Nyman wrote: > >> In this case we read the register when hub thread asks to clear port feature. >> >> why portsc returns 0x is a another question, could the hub thread be >> running while xhci controller is (in D3)? >> Was xhci runtime suspended? > > How do I tell? > Should I disable SUSPEND support and all kinds of power management? I compiled a minimal kernel, with lots of irrelevant drivers and frameworks left out, including power management. I still get the "xHCI host controller not responding, assume dead" issue. PLUG [ 59.803499] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd [ 59.836902] usb 2-2: New USB device found, idVendor=0951, idProduct=1666 [ 59.843653] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 59.850900] usb 2-2: Product: DataTraveler 3.0 [ 59.855417] usb 2-2: Manufacturer: Kingston [ 59.859661] usb 2-2: SerialNumber: 002618887865F0C0F8646BFA [ 59.868249] usb-storage 2-2:1.0: USB Mass Storage device detected [ 59.874691] scsi host0: usb-storage 2-2:1.0 [ 60.882801] scsi 0:0:0:0: Direct-Access Kingston DataTraveler 3.0 PQ: 0 ANSI: 6 [ 60.891640] sd 0:0:0:0: [sda] 15109516 512-byte logical blocks: (7.74 GB/7.20 GiB) [ 60.899662] sd 0:0:0:0: [sda] Write Protect is off [ 60.904763] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 60.916154] sda: sda1 [ 60.919798] sd 0:0:0:0: [sda] Attached SCSI removable disk UNPLUG [ 70.545087] pcieport :00:00.0: AER: Uncorrected (Non-Fatal) error received: id= [ 70.553169] pcieport :00:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, id=(Requester ID) [ 70.565084] pcieport :00:00.0: device [1105:0024] error status/mask=4000/ [ 70.573528] pcieport :00:00.0:[14] Completion Timeout (First) [ 70.580402] pcieport :00:00.0: AER: Device recovery failed [ 71.275253] xhci_hcd :01:00.0: xHCI host controller not responding, assume dead [ 71.282956] xhci_hcd :01:00.0: HC died; cleaning up [ 71.288304] usb 2-2: USB disconnect, device number 2 [ 71.293445] pcieport :00:00.0: AER: Uncorrected (Non-Fatal) error received: id= [ 71.301851] pcieport :00:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, id=(Requester ID) [ 71.313785] pcieport :00:00.0: device [1105:0024] error status/mask=4000/ [ 71.322240] pcieport :00:00.0:[14] Completion Timeout (First) [ 71.329115] pcieport :00:00.0: AER: Device recovery failed [ 71.335042] pcieport :00:00.0: AER: Uncorrected (Non-Fatal) error received: id= [ 71.343137] pcieport :00:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, id=(Requester ID) [ 71.354984] pcieport :00:00.0: device [1105:0024] error status/mask=4000/ [ 71.363443] pcieport :00:00.0:[14] Completion Timeout (First) [ 71.370289] pcieport :00:00.0: AER: Device recovery failed defconfig for reference # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_NO_HZ_IDLE=y CONFIG_HIGH_RES_TIMERS=y # CONFIG_COMPAT_BRK is not set CONFIG_SLAB=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_ARCH_TANGO=y # CONFIG_ARM_ERRATA_643719 is not set CONFIG_PCI=y CONFIG_PCIEPORTBUS=y CONFIG_PCI_MSI=y CONFIG_PCIE_TANGO_SMP8759=y CONFIG_SMP=y CONFIG_PREEMPT=y CONFIG_HZ_300=y CONFIG_AEABI=y CONFIG_HIGHMEM=y # CONFIG_ATAGS is not set CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_VFP=y CONFIG_NEON=y # CONFIG_SUSPEND is not set CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_BLK_DEV_LOOP=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y # CONFIG_INPUT_KEYBOARD is not set # CONFIG_INPUT_MOUSE is not set # CONFIG_SERIO is not set CONFIG_SERIAL_8250=y # CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_RT288X=y CONFIG_SERIAL_OF_PLATFORM=y # CONFIG_HW_RANDOM is not set # CONFIG_HWMON is not set # CONFIG_HID is not set # CONFIG_USB_HID is not set CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_STORAGE=y CONFIG_VFAT_FS=m CONFIG_TMPFS=y CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_UTF8=m CONFIG_PRINTK_TIME=y -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression between 4.9 and 4.13
On 23/08/2017 13:11, Mathias Nyman wrote:
> On 23.08.2017 12:31, Mason wrote:
>
>> [ 46.525247] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd
>> [ 46.565496] usb-storage 2-2:1.0: USB Mass Storage device detected
>> [ 46.571934] scsi host0: usb-storage 2-2:1.0
>> [ 47.601227] scsi 0:0:0:0: Direct-Access Kingston DataTraveler 3.0
>> PQ: 0 ANSI: 6
>> [ 47.611340] sd 0:0:0:0: [sda] 15109516 512-byte logical blocks: (7.74
>> GB/7.20 GiB)
>> [ 47.621624] sd 0:0:0:0: [sda] Write Protect is off
>> [ 47.627131] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled,
>> doesn't support DPO or FUA
>> [ 47.639637] sda: sda1
>> [ 47.648091] sd 0:0:0:0: [sda] Attached SCSI removable disk
>> [ 58.100306] xhci_hcd :01:00.0: xHCI host controller not responding,
>> assume dead
>> [ 58.108021] CPU: 0 PID: 939 Comm: kworker/0:2 Tainted: G C
>> 4.13.0-rc6 #11
>> [ 58.115976] Hardware name: Sigma Tango DT
>> [ 58.120016] Workqueue: usb_hub_wq hub_event
>> [ 58.124241] [] (unwind_backtrace) from []
>> (show_stack+0x10/0x14)
>> [ 58.132033] [] (show_stack) from []
>> (dump_stack+0x84/0x98)
>> [ 58.139302] [] (dump_stack) from []
>> (xhci_hc_died.part.9+0x50/0x23c)
>> [ 58.147438] [] (xhci_hc_died.part.9) from []
>> (xhci_hub_control+0xf3c/0x175c)
>> [ 58.156273] [] (xhci_hub_control) from []
>> (usb_hcd_submit_urb+0x264/0x814)
>> [ 58.164932] [] (usb_hcd_submit_urb) from []
>> (usb_start_wait_urb+0x4c/0xbc)
>> [ 58.173591] [] (usb_start_wait_urb) from []
>> (usb_control_msg+0xa0/0xcc)
>> [ 58.181985] [] (usb_control_msg) from []
>> (usb_clear_port_feature+0x44/0x4c)
>> [ 58.190730] [] (usb_clear_port_feature) from []
>> (hub_port_reset+0x228/0x51c)
>> [ 58.199561] [] (hub_port_reset) from []
>> (hub_event+0x87c/0x108c)
>> [ 58.207349] [] (hub_event) from []
>> (process_one_work+0x1d8/0x3f0)
>> [ 58.215220] [] (process_one_work) from []
>> (worker_thread+0x38/0x554)
>> [ 58.223354] [] (worker_thread) from []
>> (kthread+0x108/0x138)
>> [ 58.230789] [] (kthread) from []
>> (ret_from_fork+0x14/0x3c)
>> [ 58.238056] xhci_hcd :01:00.0: HC died; cleaning up
>> [ 58.243391] usb 2-2: USB disconnect, device number 2
>
> xhci driver reads 0x from a mmio mapped xhci portsc register and
> bails out in:
> xhci-hub.c:
> temp = readl(port_array[wIndex]);
> if (temp == ~(u32)0) {
> xhci_hc_died(xhci);
> retval = -ENODEV;
> break;
> }
>
> In this case we read the register when hub thread asks to clear port feature.
>
> why portsc returns 0x is a another question, could the hub thread be
> running while xhci controller is (in D3)?
> Was xhci runtime suspended?
How do I tell?
Should I disable SUSPEND support and all kinds of power management?
> There were some pcieport errors in another log you showed, maybe PCI devices
> are not properly recovered
> and the registers return 0x?
FWIW, I just compiled v4.12-rc1 and I do get the broken behavior.
v4.11.12 = OK
v4.12-rc1 = KO
PLUG
[ 17.226953] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd
[ 17.267195] usb-storage 2-2:1.0: USB Mass Storage device detected
[ 17.273612] scsi host0: usb-storage 2-2:1.0
[ 18.296369] scsi 0:0:0:0: Direct-Access Kingston DataTraveler 3.0
PQ: 0 ANSI: 6
[ 18.307772] sd 0:0:0:0: [sda] 15109516 512-byte logical blocks: (7.74
GB/7.20 GiB)
[ 18.316991] sd 0:0:0:0: [sda] Write Protect is off
[ 18.322588] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled,
doesn't support DPO or FUA
[ 18.334828] sda: sda1
[ 18.339507] sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 18.366202] random: fast init done
UNPLUG
[ 21.314111] pcieport :00:00.0: AER: Uncorrected (Non-Fatal) error
received: id=
[ 21.322219] pcieport :00:00.0: PCIe Bus Error: severity=Uncorrected
(Non-Fatal), type=Transaction Layer, id=(Requester ID)
[ 21.334039] pcieport :00:00.0: device [1105:0024] error
status/mask=4000/
[ 21.342453] pcieport :00:00.0:[14] Completion Timeout (First)
[ 21.349306] pcieport :00:00.0: AER: Device recovery failed
[ 22.055471] xhci_hcd :01:00.0: xHCI host controller not responding,
assume dead
[ 22.063187] xhci_hcd :01:00.0: HC died; cleaning up
[ 22.068523] usb 2-2: USB disconnect, device number 2
[ 22.073774] pcieport :00:00.0: AER: Uncorrected (Non-Fatal) error
received: id=
[ 22.085369] pcieport :00:00.0: PCIe Bus Error: severity=Uncorrected
(Non-Fatal), type=Transaction Layer, id=(Requester ID)
[ 22.098823] pcieport :00:00.0: device [1105:0024] error
status/mask=4000/
[ 22.107245] pcieport :00:00.0:[14] Completion Timeout (First)
[ 22.114130] pcieport :00:00.0: AER: Device recovery failed
[ 22.120026] pcieport :00:00.0: AER
Re: Possible regression between 4.9 and 4.13
On 23.08.2017 12:31, Mason wrote:
On 23/08/2017 09:51, Mathias Nyman wrote:
very likely cause is the more aggressive detection of pci removed xhci hosts
See commit d9f11ba9f107aa335091ab8d7ba5eea714e46e8b
xhci: Rework how we handle unresponsive or hoptlug removed hosts
It checks if a xhci register reads returns 0x and assumes xhci
died in that case.
Could you add something like the below to check which what is killing the host?
Or a BUG()/WARN() in xhci_hc_died() to get a backtrace of who called it.
[ 46.525247] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd
[ 46.565496] usb-storage 2-2:1.0: USB Mass Storage device detected
[ 46.571934] scsi host0: usb-storage 2-2:1.0
[ 47.601227] scsi 0:0:0:0: Direct-Access Kingston DataTraveler 3.0
PQ: 0 ANSI: 6
[ 47.611340] sd 0:0:0:0: [sda] 15109516 512-byte logical blocks: (7.74
GB/7.20 GiB)
[ 47.621624] sd 0:0:0:0: [sda] Write Protect is off
[ 47.627131] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled,
doesn't support DPO or FUA
[ 47.639637] sda: sda1
[ 47.648091] sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 58.100306] xhci_hcd :01:00.0: xHCI host controller not responding,
assume dead
[ 58.108021] CPU: 0 PID: 939 Comm: kworker/0:2 Tainted: G C
4.13.0-rc6 #11
[ 58.115976] Hardware name: Sigma Tango DT
[ 58.120016] Workqueue: usb_hub_wq hub_event
[ 58.124241] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 58.132033] [] (show_stack) from []
(dump_stack+0x84/0x98)
[ 58.139302] [] (dump_stack) from []
(xhci_hc_died.part.9+0x50/0x23c)
[ 58.147438] [] (xhci_hc_died.part.9) from []
(xhci_hub_control+0xf3c/0x175c)
[ 58.156273] [] (xhci_hub_control) from []
(usb_hcd_submit_urb+0x264/0x814)
[ 58.164932] [] (usb_hcd_submit_urb) from []
(usb_start_wait_urb+0x4c/0xbc)
[ 58.173591] [] (usb_start_wait_urb) from []
(usb_control_msg+0xa0/0xcc)
[ 58.181985] [] (usb_control_msg) from []
(usb_clear_port_feature+0x44/0x4c)
[ 58.190730] [] (usb_clear_port_feature) from []
(hub_port_reset+0x228/0x51c)
[ 58.199561] [] (hub_port_reset) from []
(hub_event+0x87c/0x108c)
[ 58.207349] [] (hub_event) from []
(process_one_work+0x1d8/0x3f0)
[ 58.215220] [] (process_one_work) from []
(worker_thread+0x38/0x554)
[ 58.223354] [] (worker_thread) from []
(kthread+0x108/0x138)
[ 58.230789] [] (kthread) from []
(ret_from_fork+0x14/0x3c)
[ 58.238056] xhci_hcd :01:00.0: HC died; cleaning up
[ 58.243391] usb 2-2: USB disconnect, device number 2
--
xhci driver reads 0x from a mmio mapped xhci portsc register and bails
out in:
xhci-hub.c:
temp = readl(port_array[wIndex]);
if (temp == ~(u32)0) {
xhci_hc_died(xhci);
retval = -ENODEV;
break;
}
In this case we read the register when hub thread asks to clear port feature.
why portsc returns 0x is a nother quiestion, could the hub thread be
running while xhci controller is (in D3)?
Was xhci runtime suspended?
There were some pcieport errors in another log you showed, maybe PCI devices
are not properly recovered
and the registers return 0x?
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb:xhci:Fix regression when ATI chipsets detected
From: Sandeep Singh
The following commit cause a regression on ATI chipsets.
'commit e788787ef4f9 ("usb:xhci:Add quirk for Certain
failing HP keyboard on reset after resume")'
This causes pinfo->smbus_dev to be wrongly set to NULL on
systems with the ATI chipset that this function checks for first.
Added conditional check for AMD chipsets to avoid the overwriting
pinfo->smbus_dev.
Reported-by: Ben Hutchings
Signed-off-by: Sandeep Singh
Signed-off-by: Shyam Sundar S K
cc: Nehal Shah
---
drivers/usb/host/pci-quirks.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 5f4ca78..58b9685 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -142,29 +142,30 @@ static int amd_chipset_sb_type_init(struct
amd_chipset_info *pinfo)
pinfo->sb_type.gen = AMD_CHIPSET_SB700;
else if (rev >= 0x40 && rev <= 0x4f)
pinfo->sb_type.gen = AMD_CHIPSET_SB800;
- }
- pinfo->smbus_dev = pci_get_device(PCI_VENDOR_ID_AMD,
- 0x145c, NULL);
- if (pinfo->smbus_dev) {
- pinfo->sb_type.gen = AMD_CHIPSET_TAISHAN;
} else {
pinfo->smbus_dev = pci_get_device(PCI_VENDOR_ID_AMD,
PCI_DEVICE_ID_AMD_HUDSON2_SMBUS, NULL);
- if (!pinfo->smbus_dev) {
- pinfo->sb_type.gen = NOT_AMD_CHIPSET;
- return 0;
+ if (pinfo->smbus_dev) {
+ rev = pinfo->smbus_dev->revision;
+ if (rev >= 0x11 && rev <= 0x14)
+ pinfo->sb_type.gen = AMD_CHIPSET_HUDSON2;
+ else if (rev >= 0x15 && rev <= 0x18)
+ pinfo->sb_type.gen = AMD_CHIPSET_BOLTON;
+ else if (rev >= 0x39 && rev <= 0x3a)
+ pinfo->sb_type.gen = AMD_CHIPSET_YANGTZE;
+ } else {
+ pinfo->smbus_dev = pci_get_device(PCI_VENDOR_ID_AMD,
+ 0x145c, NULL);
+ if (pinfo->smbus_dev) {
+ rev = pinfo->smbus_dev->revision;
+ pinfo->sb_type.gen = AMD_CHIPSET_TAISHAN;
+ } else {
+ pinfo->sb_type.gen = NOT_AMD_CHIPSET;
+ return 0;
+ }
}
-
- rev = pinfo->smbus_dev->revision;
- if (rev >= 0x11 && rev <= 0x14)
- pinfo->sb_type.gen = AMD_CHIPSET_HUDSON2;
- else if (rev >= 0x15 && rev <= 0x18)
- pinfo->sb_type.gen = AMD_CHIPSET_BOLTON;
- else if (rev >= 0x39 && rev <= 0x3a)
- pinfo->sb_type.gen = AMD_CHIPSET_YANGTZE;
}
-
pinfo->sb_type.rev = rev;
return 1;
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression between 4.9 and 4.13
On 23/08/2017 09:51, Mathias Nyman wrote: > very likely cause is the more aggressive detection of pci removed xhci hosts > > See commit d9f11ba9f107aa335091ab8d7ba5eea714e46e8b > xhci: Rework how we handle unresponsive or hoptlug removed hosts > > It checks if a xhci register reads returns 0x and assumes xhci > died in that case. I've just tested 4.11.12 + a few local patches to back-port PCIe host bridge support. It "works" as well as 4.9 (i.e. modulo the "AER: Uncorrected (Non-Fatal) error received") [0.508533] pcie_tango 5000.pcie: simultaneous PCI config and MMIO accesses may cause data corruption [0.519622] OF: PCI: host bridge /soc/pcie@2e000 ranges: [0.519645] OF: PCI: MEM 0x5040..0x53ff -> 0x0040 [0.519725] pcie_tango 5000.pcie: ECAM at [mem 0x5000-0x503f] for [bus 00-03] [0.519872] pcie_tango 5000.pcie: PCI host bridge to bus :00 [0.519886] pci_bus :00: root bus resource [bus 00-03] [0.519898] pci_bus :00: root bus resource [mem 0x5040-0x53ff] (bus address [0x0040-0x03ff]) [0.520201] PCI: bus0: Fast back to back transfers disabled [0.520213] pci :00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring [0.520922] PCI: bus1: Fast back to back transfers disabled [0.520964] pci :00:00.0: of_irq_parse_pci: failed with rc=-22 [0.520993] pci :00:00.0: BAR 8: assigned [mem 0x5040-0x504f] [0.521004] pci :01:00.0: BAR 0: assigned [mem 0x5040-0x50401fff 64bit] [0.521025] pci :00:00.0: PCI bridge to [bus 01] [0.521033] pci :00:00.0: bridge window [mem 0x5040-0x504f] [0.521085] pcieport :00:00.0: enabling device (0140 -> 0142) [0.521282] pcieport :00:00.0: Signaling PME with IRQ 30 [0.521402] pcieport :00:00.0: AER enabled with IRQ 30 [0.521526] pci :01:00.0: enabling device (0140 -> 0142) ... [1.239706] xhci_hcd :01:00.0: xHCI Host Controller [1.244998] xhci_hcd :01:00.0: new USB bus registered, assigned bus number 1 [1.258048] xhci_hcd :01:00.0: hcc params 0x014051cf hci version 0x100 quirks 0x0010 [1.267467] hub 1-0:1.0: USB hub found [1.271287] hub 1-0:1.0: 4 ports detected [1.275761] xhci_hcd :01:00.0: xHCI Host Controller [1.281048] xhci_hcd :01:00.0: new USB bus registered, assigned bus number 2 [1.288578] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM. [1.297234] hub 2-0:1.0: USB hub found [1.301042] hub 2-0:1.0: 4 ports detected [1.305681] usbcore: registered new interface driver usb-storage PLUG #1 [ 26.104607] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd [ 26.143799] usb-storage 2-2:1.0: USB Mass Storage device detected [ 26.150253] scsi host0: usb-storage 2-2:1.0 [ 27.177298] scsi 0:0:0:0: Direct-Access Kingston DataTraveler 3.0 PQ: 0 ANSI: 6 [ 27.187586] sd 0:0:0:0: [sda] 15109516 512-byte logical blocks: (7.74 GB/7.20 GiB) [ 27.199000] sd 0:0:0:0: [sda] Write Protect is off [ 27.204186] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 27.216322] sda: sda1 [ 27.220584] sd 0:0:0:0: [sda] Attached SCSI removable disk [ 27.252046] random: fast init done UNPLUG #1 [ 37.334040] pcieport :00:00.0: AER: Uncorrected (Non-Fatal) error received: id= [ 37.342135] pcieport :00:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, id=(Requester ID) [ 37.353970] pcieport :00:00.0: device [1105:0024] error status/mask=4000/ [ 37.362589] pcieport :00:00.0:[14] Completion Timeout (First) [ 37.369485] pcieport :00:00.0: AER: Device recovery failed [ 38.066538] xhci_hcd :01:00.0: Cannot set link state. [ 38.072039] usb usb2-port2: cannot disable (err = -32) [ 38.077348] usb 2-2: USB disconnect, device number 2 [ 38.082711] pcieport :00:00.0: AER: Uncorrected (Non-Fatal) error received: id= [ 38.094279] pcieport :00:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, id=(Requester ID) [ 38.108006] pcieport :00:00.0: device [1105:0024] error status/mask=4000/ [ 38.116878] pcieport :00:00.0:[14] Completion Timeout (First) [ 38.123954] pcieport :00:00.0: AER: Device recovery failed PLUG #2 [ 55.097922] usb 2-2: new SuperSpeed USB device number 3 using xhci_hcd [ 55.137590] usb-storage 2-2:1.0: USB Mass Storage device detected [ 55.144016] scsi host0: usb-storage 2-2:1.0 [ 56.163907] scsi 0:0:0:0: Direct-Access Kingston DataTraveler 3.0 PQ: 0 ANSI: 6 [ 56.174851] sd 0:0:0:0: [sda] 15109516 512-byte logical blocks: (7.74 GB/7.20 GiB) [ 56.184218] sd 0:0:0:0: [sda] Write Protect is off [ 56.190162] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [
Re: Possible regression between 4.9 and 4.13
On 23/08/2017 09:51, Mathias Nyman wrote: > very likely cause is the more aggressive detection of pci removed xhci hosts > > See commit d9f11ba9f107aa335091ab8d7ba5eea714e46e8b > xhci: Rework how we handle unresponsive or hoptlug removed hosts > > It checks if a xhci register reads returns 0x and assumes xhci > died in that case. > > Could you add something like the below to check which what is killing the > host? > Or a BUG()/WARN() in xhci_hc_died() to get a backtrace of who called it. [ 46.525247] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd [ 46.565496] usb-storage 2-2:1.0: USB Mass Storage device detected [ 46.571934] scsi host0: usb-storage 2-2:1.0 [ 47.601227] scsi 0:0:0:0: Direct-Access Kingston DataTraveler 3.0 PQ: 0 ANSI: 6 [ 47.611340] sd 0:0:0:0: [sda] 15109516 512-byte logical blocks: (7.74 GB/7.20 GiB) [ 47.621624] sd 0:0:0:0: [sda] Write Protect is off [ 47.627131] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 47.639637] sda: sda1 [ 47.648091] sd 0:0:0:0: [sda] Attached SCSI removable disk [ 58.100306] xhci_hcd :01:00.0: xHCI host controller not responding, assume dead [ 58.108021] CPU: 0 PID: 939 Comm: kworker/0:2 Tainted: G C 4.13.0-rc6 #11 [ 58.115976] Hardware name: Sigma Tango DT [ 58.120016] Workqueue: usb_hub_wq hub_event [ 58.124241] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 58.132033] [] (show_stack) from [] (dump_stack+0x84/0x98) [ 58.139302] [] (dump_stack) from [] (xhci_hc_died.part.9+0x50/0x23c) [ 58.147438] [] (xhci_hc_died.part.9) from [] (xhci_hub_control+0xf3c/0x175c) [ 58.156273] [] (xhci_hub_control) from [] (usb_hcd_submit_urb+0x264/0x814) [ 58.164932] [] (usb_hcd_submit_urb) from [] (usb_start_wait_urb+0x4c/0xbc) [ 58.173591] [] (usb_start_wait_urb) from [] (usb_control_msg+0xa0/0xcc) [ 58.181985] [] (usb_control_msg) from [] (usb_clear_port_feature+0x44/0x4c) [ 58.190730] [] (usb_clear_port_feature) from [] (hub_port_reset+0x228/0x51c) [ 58.199561] [] (hub_port_reset) from [] (hub_event+0x87c/0x108c) [ 58.207349] [] (hub_event) from [] (process_one_work+0x1d8/0x3f0) [ 58.215220] [] (process_one_work) from [] (worker_thread+0x38/0x554) [ 58.223354] [] (worker_thread) from [] (kthread+0x108/0x138) [ 58.230789] [] (kthread) from [] (ret_from_fork+0x14/0x3c) [ 58.238056] xhci_hcd :01:00.0: HC died; cleaning up [ 58.243391] usb 2-2: USB disconnect, device number 2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression between 4.9 and 4.13
On 23/08/2017 09:51, Mathias Nyman wrote: > On 23.08.2017 09:07, Felipe Balbi wrote: > >> Mason writes: >> >>> Any idea what could have changed between 4.9 and 4.13 ? >> >> Quite a bit: >> >> $ git rev-list --no-merges --count v4.13-rc6 ^v4.9 -- drivers/usb/host/xhci >> drivers/usb/core/ >> 58 > > very likely cause is the more aggressive detection of pci removed xhci hosts > > See commit d9f11ba9f107aa335091ab8d7ba5eea714e46e8b > xhci: Rework how we handle unresponsive or hoptlug removed hosts > > It checks if a xhci register reads returns 0x and assumes xhci > died in that case. > > Could you add something like the below to check which what is killing the > host? > Or a BUG()/WARN() in xhci_hc_died() to get a backtrace of who called it. > > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c > index 51cd4b8..ade2ad6 100644 > --- a/drivers/usb/host/xhci-ring.c > +++ b/drivers/usb/host/xhci-ring.c > @@ -922,7 +922,8 @@ void xhci_hc_died(struct xhci_hcd *xhci) > if (xhci->xhc_state & XHCI_STATE_DYING) > return; > > - xhci_err(xhci, "xHCI host controller not responding, assume dead\n"); > + xhci_err(xhci, "xHC not responding in %pf, assume controller is > dead\n", > +__builtin_return_address(0)); > xhci->xhc_state |= XHCI_STATE_DYING; > > xhci_cleanup_command_queue(xhci); I'll try some coarse bisection to narrow it down. $ git describe --contains d9f11ba9f107aa335091ab8d7ba5eea714e46e8b v4.12-rc1~97^2~39 I'll check 4.11 first. I wanted to mention that the XHCI setup on 4.9 and 4.13 print slightly different things (at the beginning). On 4.9 [1.240322] xhci_hcd :01:00.0: xHCI Host Controller [1.245617] xhci_hcd :01:00.0: new USB bus registered, assigned bus number 1 [1.258691] xhci_hcd :01:00.0: hcc params 0x014051cf hci version 0x100 quirks 0x0010 [1.268090] hub 1-0:1.0: USB hub found [1.271905] hub 1-0:1.0: 4 ports detected [1.276372] xhci_hcd :01:00.0: xHCI Host Controller [1.281645] xhci_hcd :01:00.0: new USB bus registered, assigned bus number 2 [1.289173] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM. [1.297775] hub 2-0:1.0: USB hub found [1.301577] hub 2-0:1.0: 4 ports detected [1.306194] usbcore: registered new interface driver usb-storage On 4.13 [1.222471] pcieport :00:00.0: of_irq_parse_pci: failed with rc=-22 [1.229156] xhci_hcd :01:00.0: Resetting [2.268836] xhci_hcd :01:00.0: xHCI Host Controller [2.274126] xhci_hcd :01:00.0: new USB bus registered, assigned bus number 1 [2.287222] xhci_hcd :01:00.0: hcc params 0x014051cf hci version 0x100 quirks 0x0010 [2.296653] hub 1-0:1.0: USB hub found [2.300478] hub 1-0:1.0: 4 ports detected [2.304962] xhci_hcd :01:00.0: xHCI Host Controller [2.310246] xhci_hcd :01:00.0: new USB bus registered, assigned bus number 2 [2.317776] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM. [2.326419] hub 2-0:1.0: USB hub found [2.330229] hub 2-0:1.0: 4 ports detected [2.334869] usbcore: registered new interface driver usb-storage FWIW, "of_irq_parse_pci: failed with rc=-22" seems to come from: [1.257411] [] (of_irq_parse_pci) from [] (of_irq_parse_and_map_pci+0x10/0x2c) [1.266420] [] (of_irq_parse_and_map_pci) from [] (pci_assign_irq+0x78/0xb0) [1.275254] [] (pci_assign_irq) from [] (pci_device_probe+0x18/0x128) [1.283476] [] (pci_device_probe) from [] (driver_probe_device+0x244/0x2c8) The error logging was added by f1aa54840657f No, that just turned one specific error into a warning. Need to dig a bit more. Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Web camera USB bandwidth allocation
Hi,
What happens when you try to use the fourth camera?
I'm sorry I forgot to write whet the actual problem is. Error message is
"No space left on device". Based on what I read this means there it
can't allocate enough bandwidth.
Using this command (cat /sys/kernel/debug/usb/devices | grep "B: "), I
could see bandwidth allocation if cameras are connected to USB 2.0, but
not if connected to 3.0 port. With this command and usbtop I created
this table.
+-+--+--++
| Resolution | Name | Bandwidth allocation | Transfer rate |
+-+--+--++
| 1280x720| 720p | 256us| up to ~1.4Mb/s |
| 1600x896| | 424us| up to ~1.7Mb/s |
| 1920x1080 | Full HD | 488us| up to ~1.8Mb/s |
+-+--+--++
On USB 2.0 port there is 800us available bandwidth, that means i could
run cameras in this modes:
-3 cameras in 720p (used 96% of bandwidth)
-one camera in 720p and one camera in FullHD
On USB 3.0 port I can run cameras in same formats as on USB 2.0 and
additionally
-one camera in FullHD and one camera in 1600x896
I currently don't have 4 cameras, but I suppose that if we can make
cameras to work on higher resolutions, I could add more cameras.
Cameras are connected trough TP-LINK 3.0 USB hub (Model: UH720), but
there is no difference if I connect one camera directly and other over hub.
Then while running with 3 cameras, make a copy of
/sys/kernel/debug/usb/devices and post the copy.
I added attachment.
Also, what version of the kernel are you using?
Linux odroid 4.9.38
and which host controller? (xhci, ehci, ohci, uhci)
Using this code:
struct v4l2_capability caps = {};
if (-1 == xioctl(fd, VIDIOC_QUERYCAP, &caps))
{
perror("Querying Capabilities");
return 1;
}
printf( "Driver Caps:\n"
" Driver: \"%s\"\n"
" Card: \"%s\"\n"
" Bus: \"%s\"\n"
" Version: %d.%d\n"
" Capabilities: %08x\n",
caps.driver,
caps.card,
caps.bus_info,
(caps.version>>16)&&0xff,
(caps.version>>24)&&0xff,
caps.capabilities);
It says "usb-xhci-hcd.2.auto-1.1.1.4".
On 23. 08. 2017 08:04, Felipe Balbi wrote:
Hi,
Alan Stern writes:
On Tue, 22 Aug 2017, Martin Oprešnik wrote:
Hello,
we are working on a project, where we need multiple cameras connected to
embedded computer. For computer we have chosen odroid XU4 and for
cameras Logitech C920. We need at least 5 cameras running with 720p. The
problem we have is allocated USB bandwidth (cameras are using
isochronous transfer). Currently we can run 3 cameras on 720p. Image is
transferred in h264 compressed format. Writing on disk is done directly
trough memory map using V4L2 api and files on disk are really small and
using usbmon/wireshark shows ~1104kB/s (there should be a lot of USB
bandwidth left).
What happens when you try to use the fourth camera?
I tried same setups on my laptop and I don't get any better results, so
I suspect there is some space for improvement in software and it's not
odroid's fault. I tried changing different parameters in uvcvideo driver
and I think only wMaxPacketSize is affecting bandwidth allocation. And
changing that is reflected in non working camera.
Now I don't know enough about USB and linux kernel to work around this
problem and I would be very happy if you could give me some help or
directions.
If I should provide some additional information, I'll be happy to add it.
I am looking forward to hearing from you.
Please try the following. First, mount a debugfs filesystem:
mount -t debugfs none /sys/kernel/debug
Then while running with 3 cameras, make a copy of
/sys/kernel/debug/usb/devices and post the copy.
Also, what version of the kernel are you using?
and which host controller? (xhci, ehci, ohci, uhci)
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 3
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev= 4.09
S: Manufacturer=Linux 4.9.38 ehci_hcd
S: Product=EHCI Host Controller
S: SerialNumber=1211.usb:
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 3
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0001 Rev= 4.09
S: Manufacturer=Linux 4.9.38 ohci_hcd
S: Product=USB Host Controller
S: SerialNumber=1212.usb:
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub
Re: [PATCH] usb: reducing an usb-port auto-resume latency.
On 23.08.2017 09:18, anshuman.gu...@intel.com wrote: From: Anshuman Gupta This patch will improve the variable auto-resume latency of an usb-port. When xhci gets a port status change event interrupt due to PORT_PLC (port link state transition), linux Host controller driver drives the resume signalling on the bus for the amount of time defined by USB_REUME_TIMEOUT(40ms) macro. This 40ms delay for resume signalling is in acceptable limit, but it get worse when xhci goes for polling mode in order to detect other events on its ports and modify rh_timer timer with a variable time out of 1ms to (HZ/4)ms. drivers/usb/core/hcd.c line 799 mod_timer (&hcd->rh_timer, (jiffies/(HZ/4) + 1) * (HZ/4)). Due to above variable timeout usb auto-resume latency varies from 40ms to ~300ms. Log Snippet: ~128ms latency [ 53.112049] hub 1-0:1.0: state 7 ports 12 chg evt [ 53.229200] hub 1-0:1.0: state 7 ports 12 chg evt 0004 [ 53.240177] usb 1-2: usb wakeup-resume [ 53.240195] usb 1-2: finish resume [ 53.240357] usb usb1-port2: resume, status 0 - ~300ms latency [ 59.946620] hub 1-0:1.0: state 7 ports 12 chg evt [ 59.979341] hub 1-0:1.0: state 7 ports 12 chg evt [ 60.229342] hub 1-0:1.0: state 7 ports 12 chg evt 0004 [ 60.251321] usb 1-2: usb wakeup-resume [ 60.251335] usb 1-2: finish resume [ 60.251539] usb usb1-port2: resume, status 0 This variable resume latency can be optimized, as in case of PORT_PLC change event rh_timer has already been modified with USB_RESUME_TIMEOUT (40ms) delay,leaving the rest to GetPortStatus and started polling for root hub status (invoking usb_hcd_poll_rh_status). We can avoid polling as we have already modified rh_timer with delay of 40ms. This patch set the HCD_FLAG_POLL_RH to hcd->flags after modification of rh_timer, and avoids polling of root hub status. so rh_timer can fire after 40ms and usb device auto-resuem latency will be around 40ms. Signed-off-by: Anshuman Gupta --- Thanks, adding and sending forward after 4.14-rc1 -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression between 4.9 and 4.13
On 23.08.2017 09:07, Felipe Balbi wrote: Hi, Mason writes: Hello, The driver for my system's PCIe host bridge landed recently (in 4.13) but it was developed on 4.9 I tested the PCIe host bridge by plugging a 4-port USB3 adapter into the PCIe slot (system at rest) and plugging an USB3 Flash drive into the USB3 adapter (at run-time). On 4.9, the setup works (almost perfectly, see below). On 4.13, once I unplug the Flash drive, the controller port remains unresponsive. On 4.9, I said *almost* perfectly, because the pcieport driver does report a few non-fatal errors when I unplug: [ 193.838504] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd [ 193.878081] usb-storage 2-2:1.0: USB Mass Storage device detected [ 193.884547] scsi host0: usb-storage 2-2:1.0 [ 194.907936] scsi 0:0:0:0: Direct-Access Kingston DataTraveler 3.0 PQ: 0 ANSI: 6 [ 194.920296] sd 0:0:0:0: [sda] 15109516 512-byte logical blocks: (7.74 GB/7.20 GiB) [ 194.928666] sd 0:0:0:0: [sda] Write Protect is off [ 194.933755] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 194.946074] sda: sda1 [ 194.953608] sd 0:0:0:0: [sda] Attached SCSI removable disk [ 208.930260] pcieport :00:00.0: AER: Uncorrected (Non-Fatal) error received: id= [ 208.938342] pcieport :00:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, id=(Requester ID) [ 208.950163] pcieport :00:00.0: device [1105:0024] error status/mask=4000/ [ 208.958577] pcieport :00:00.0:[14] Completion Timeout (First) [ 208.965432] pcieport :00:00.0: AER: Device recovery failed [ 209.663733] xhci_hcd :01:00.0: Cannot set link state. [ 209.669194] usb usb2-port2: cannot disable (err = -32) [ 209.674376] usb 2-2: USB disconnect, device number 2 [ 209.680481] pcieport :00:00.0: AER: Uncorrected (Non-Fatal) error received: id= [ 209.688689] pcieport :00:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, id=(Requester ID) [ 209.700555] pcieport :00:00.0: device [1105:0024] error status/mask=4000/ [ 209.708978] pcieport :00:00.0:[14] Completion Timeout (First) [ 209.715845] pcieport :00:00.0: AER: Device recovery failed [ 209.721722] pcieport :00:00.0: AER: Uncorrected (Non-Fatal) error received: id= [ 209.729785] pcieport :00:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, id=(Requester ID) [ 209.741602] pcieport :00:00.0: device [1105:0024] error status/mask=4000/ [ 209.750027] pcieport :00:00.0:[14] Completion Timeout (First) [ 209.756866] pcieport :00:00.0: AER: Device recovery failed After that, I can still plug the drive into the same port. But on 4.13, I get [ 27.330378] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd [ 27.369383] usb-storage 2-2:1.0: USB Mass Storage device detected [ 27.375840] scsi host0: usb-storage 2-2:1.0 [ 28.403035] scsi 0:0:0:0: Direct-Access Kingston DataTraveler 3.0 PQ: 0 ANSI: 6 [ 28.413326] sd 0:0:0:0: [sda] 15109516 512-byte logical blocks: (7.74 GB/7.20 GiB) [ 28.423653] sd 0:0:0:0: [sda] Write Protect is off [ 28.429139] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 28.441529] sda: sda1 [ 28.449431] sd 0:0:0:0: [sda] Attached SCSI removable disk [ 90.592134] xhci_hcd :01:00.0: xHCI host controller not responding, assume dead [ 90.599857] xhci_hcd :01:00.0: HC died; cleaning up [ 90.605336] usb 2-2: USB disconnect, device number 2 [ 90.630414] udevd[955]: inotify_add_watch(6, /dev/sda, 10) failed: No such file or directory Trying to replug into the same port = nothing happens (Linux did say "assume dead") Any idea what could have changed between 4.9 and 4.13 ? Quite a bit: $ git rev-list --no-merges --count v4.13-rc6 ^v4.9 -- drivers/usb/host/xhci drivers/usb/core/ 58 very likely cause is the more aggressive detection of pci removed xhci hosts See commit d9f11ba9f107aa335091ab8d7ba5eea714e46e8b xhci: Rework how we handle unresponsive or hoptlug removed hosts It checks if a xhci register reads returns 0x and assumes xhci died in that case. Could you add something like the below to check which what is killing the host? Or a BUG()/WARN() in xhci_hc_died() to get a backtrace of who called it. diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 51cd4b8..ade2ad6 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -922,7 +922,8 @@ void xhci_hc_died(struct xhci_hcd *xhci) if (xhci->xhc_state & XHCI_STATE_DYING) return; - xhci_err(xhci, "xHCI host controller not responding, assume dead\n"); + xhci_err(xhci, "xHC not responding in %pf, assume controller is dead\n", +__builtin_return_addre
[PATCH 1/2] usb: xhci: Support enabling of compliance mode for xhci 1.1
To perform SuperSpeed compliance testing the port should first
be placed into compliance mode. For xHCI 1.0 and prior this
transition happens automatically when the port is in Training
and encounters an LFPS timeout. Thus running compliance tests
against a test appliance may simply just work by simply plugging
in to the downstream port.
However starting with xHCI 1.1 the transition from Polling.LFPS
to compliance mode may be disabled by default and needs to be
explicitly enabled by writing to the PLS field of the PORTSC
register, which sets an internal 'CTE' (Compliance Transition
Enabled) flag so that the port will perform the transition the
next time it encounters LFPS timeout. Whether this is disabled or
not is determined by the 'CTC' (Compliance Transition Capability)
bit in the HCCPARAMS2 capability register.
In order to allow a test operator to change this if needed, allow
a test driver (such as drivers/usb/misc/lvstest.c) to send a
SET_FEATURE(PORT_LINK_STATE) control message to the root hub to
update the link state prior to connecting to the port. Subsequently,
placing the port in warm reset would then disable the flag.
Signed-off-by: Jack Pham
---
drivers/usb/host/xhci-hub.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 4bc6f42..ad89a6d 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1179,6 +1179,39 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq,
u16 wValue,
break;
}
+ /*
+* For xHCI 1.1 according to section 4.19.1.2.4.1 a
+* root hub port's transition to compliance mode upon
+* detecting LFPS timeout may be controlled by an
+* Compliance Transition Enabled (CTE) flag (not
+* software visible). This flag is set by writing 0xA
+* to PORTSC PLS field which will allow transition to
+* compliance mode the next time LFPS timeout is
+* encountered. A warm reset will clear it.
+*
+* The CTE flag is only supported if the HCCPARAMS2 CTC
+* flag is set, otherwise, the compliance substate is
+* automatically entered as on 1.0 and prior.
+*/
+ if (link_state == USB_SS_PORT_LS_COMP_MOD) {
+ if (!HCC2_CTC(xhci->hcc_params2)) {
+ xhci_dbg(xhci, "CTC flag is 0, port
already supports entering compliance mode\n");
+ break;
+ }
+
+ if ((temp & PORT_CONNECT)) {
+ xhci_warn(xhci, "Can't set compliance
mode when port is connected\n");
+ goto error;
+ }
+
+ xhci_dbg(xhci, "Enable compliance mode
transition for port %d\n",
+ wIndex);
+ xhci_set_link_state(xhci, port_array, wIndex,
+ link_state);
+ temp = readl(port_array[wIndex]);
+ break;
+ }
+
/* Software should not attempt to set
* port link state above '3' (U3) and the port
* must be enabled.
--
2.9.1.200.gb1ec08f
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: misc: lvstest: add entry to place port in compliance mode
Add support for the SuperSpeed Link Layer test case TD.7.34
which requires the operator to place the port into compliance
mode, and to subsequently bring it out via reset. Historically
according to the (now deprecated) USB 3.0 specification a
SuperSpeed host downstream port would automatically transition
to Compliance mode from the Polling state if LFPS polling times
out. However the language in USB 3.1 as well as xHCI 1.1 states
it may be required to explicitly enable this transition. For
such hosts this is done by sending a SET_FEATURE(PORT_LINK_STATE)
with the state set to Compliance to the root hub port.
Similar to the other supported commands, to do this via sysfs:
echo > /sys/bus/usb/devices/2-0\:1.0/enable_compliance
According to xHCI 1.1 section 4.19.1.2.4.1, this enables the
transition to compliance mode upon LFPS timeout. Note that this
can only be issued when the port is in disconnected state. And
in order to disable this behavior on subsequent transitions, a
warm reset should be issued. So add another entry to do that:
echo > /sys/bus/usb/devices/2-0\:1.0/warm_reset
In general these attributes can also be useful for other USB
SuperSpeed compliance tests such as electrical and eye diagram
testing which require CPn patterns to be transmitted.
Signed-off-by: Jack Pham
---
Documentation/ABI/testing/sysfs-bus-usb-lvstest | 13
drivers/usb/misc/lvstest.c | 41 +
2 files changed, 54 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-usb-lvstest
b/Documentation/ABI/testing/sysfs-bus-usb-lvstest
index 5151290..ee0046d 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb-lvstest
+++ b/Documentation/ABI/testing/sysfs-bus-usb-lvstest
@@ -45,3 +45,16 @@ Contact: Pratyush Anand
Description:
Write to this node to issue "U3 exit" for Link Layer
Validation device. It is needed for TD.7.36.
+
+What: /sys/bus/usb/devices/.../enable_compliance
+Date: July 2017
+Description:
+ Write to this node to set the port to compliance mode to test
+ with Link Layer Validation device. It is needed for TD.7.34.
+
+What: /sys/bus/usb/devices/.../warm_reset
+Date: July 2017
+Description:
+ Write to this node to issue "Warm Reset" for Link Layer
Validation
+ device. It may be needed to properly reset an xHCI 1.1 host
port if
+ compliance mode needed to be explicitly enabled.
diff --git a/drivers/usb/misc/lvstest.c b/drivers/usb/misc/lvstest.c
index 2142132..d63 100644
--- a/drivers/usb/misc/lvstest.c
+++ b/drivers/usb/misc/lvstest.c
@@ -178,6 +178,25 @@ static ssize_t hot_reset_store(struct device *dev,
}
static DEVICE_ATTR_WO(hot_reset);
+static ssize_t warm_reset_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct usb_interface *intf = to_usb_interface(dev);
+ struct usb_device *hdev = interface_to_usbdev(intf);
+ struct lvs_rh *lvs = usb_get_intfdata(intf);
+ int ret;
+
+ ret = lvs_rh_set_port_feature(hdev, lvs->portnum,
+ USB_PORT_FEAT_BH_PORT_RESET);
+ if (ret < 0) {
+ dev_err(dev, "can't issue warm reset %d\n", ret);
+ return ret;
+ }
+
+ return count;
+}
+static DEVICE_ATTR_WO(warm_reset);
+
static ssize_t u2_timeout_store(struct device *dev,
struct device_attribute *attr, const char *buf, size_t count)
{
@@ -274,13 +293,35 @@ static ssize_t get_dev_desc_store(struct device *dev,
}
static DEVICE_ATTR_WO(get_dev_desc);
+static ssize_t enable_compliance_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct usb_interface *intf = to_usb_interface(dev);
+ struct usb_device *hdev = interface_to_usbdev(intf);
+ struct lvs_rh *lvs = usb_get_intfdata(intf);
+ int ret;
+
+ ret = lvs_rh_set_port_feature(hdev,
+ lvs->portnum | USB_SS_PORT_LS_COMP_MOD << 3,
+ USB_PORT_FEAT_LINK_STATE);
+ if (ret < 0) {
+ dev_err(dev, "can't enable compliance mode %d\n", ret);
+ return ret;
+ }
+
+ return count;
+}
+static DEVICE_ATTR_WO(enable_compliance);
+
static struct attribute *lvs_attributes[] = {
&dev_attr_get_dev_desc.attr,
&dev_attr_u1_timeout.attr,
&dev_attr_u2_timeout.attr,
&dev_attr_hot_reset.attr,
+ &dev_attr_warm_reset.attr,
&dev_attr_u3_entry.attr,
&dev_attr_u3_exit.attr,
+ &dev_attr_enable_compliance.attr,
NULL
};
--
2.9.1.200.gb1ec08f
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.or
[PATCH 0/2] usb: lvstest: explicit compliance mode entry/exit on xhci 1.1 hosts
Hi, This patch series aims to allow the lvstest driver to work with xHCI 1.1 hosts. In xHCI 1.1 a downstream port might not automatically enter compliance mode upon LFPS timeout; instead the port must be explicitly enabled to allow this transition. This is needed to pass the Link Layer test case TD.7.34 in which the test operator is prompted to put the port in compliance mode before proceeding with the test. This requires adding support to the xhci hub driver to accept a SET_FEATURE(PORT_LINK_STATE) request for the compliance state and a new 'enable_compliance' sysfs entry to lvstest which invokes it. Thanks, Jack Jack Pham (2): usb: xhci: Support enabling of compliance mode for xhci 1.1 usb: misc: lvstest: add entry to place port in compliance mode Documentation/ABI/testing/sysfs-bus-usb-lvstest | 13 drivers/usb/host/xhci-hub.c | 33 drivers/usb/misc/lvstest.c | 41 + 3 files changed, 87 insertions(+) -- 2.9.1.200.gb1ec08f The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
