Re: Scheduling of interrupt transfer delayed on ehci when interval not 1?
On Tue, 15 Oct 2013, Marcus Overhagen wrote: On Tue, Oct 15, 2013 at 6:07 PM, Alan Stern st...@rowland.harvard.edu wrote: Why does the driver make this mistake? My initial assumption was wrong, the driver doesn't infrequently poll, but does so more often. I was misled by the confusing source. However, I now made usbmon traces and analyzed them with LibreOffice. During data transfer, the driver does a interrupt transfer about 48ms after the last one, and has to wait about 15ms for the result. But every 40 transfers, it executes 3 transfers without waiting inbetween and has to wait 63ms for the result. This is with transfer interval set to 10 on xhci. I also compiled the driver with transfer interval set to 1 (the original setting before my patch [1]), but the result is similar, an interrupt transfer every 44ms, and waiting of 19ms for the result. I don't have ehci hardware to test it. When the URB completition callback is executed, it calles complete(), while the driver is using wait_for_completion_interruptible_timeout() for this signal with 100ms timeout (originally that was 50ms but I changed it in patch [2] to make it work with xhci) This function seems to timeout on ehci hardware after about 700MB to 7GB transfered. I guess that the thread isn't scheduled fast enough under load, although the USB transfer was successful. That could be the explanation. It would also explain why increasing the timeout fixes the problem. bInterval = 10 means the polling period is 64 ms (for a high-speed device). So a timeout of 100 ms should be adequate -- provided the device always sends data over the interrupt endpoint without any further delay. What i do not understand: with ehci hardware, the driver works when interval in the urb is set to 1 and the timeout is 50ms. With xhci, the urb appears to be scheduled not more often then every 64ms even if the interval in the urb is set to 1. This is because ehci-hcd pays attention to urb-interval whereas xhci-hcd ignores it. I'm just looking for the correct solution for this issue. Here's a suggestion: Have the URB's completion routine set a new flag somewhere. When the wait_for_completion_interruptible_timeout() call returns, check whether the new flag is set instead of checking whether a timeout occurred. 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
Scheduling of interrupt transfer delayed on ehci when interval not 1?
Hello, I made a change to the rts5139 driver that got included in kernel 3.11 (see second patch at end of this email), but Lutz Vieweg reported that the patch causes issues for him, because the driver falsely detects that the SD card is no longer present after transfer of a few 100 MBs. I do not have this issue with xhci. He is using ehci. The USB endpoint specifies a transfer interval of 10. The rts5139 driver uses the interrupt transfer to infrequently poll for card presence, but doesn't queue multiple urbs for periodic transfers. The issue seems to be a difference in how early the (first) interrupt transfer is scheduled by xhci and ehci when the interval specified in the urb is not 1. With ehci it seems to be delayed when the interval is not 1. With xhci you get warning messages in syslog if interval is not 10. My USB knowledge is too limited to properly fix this in xhci or ehci hcd. Can somebody help me? what is the correct fix for this problem? It is possible that the following patch, that increases the timeout the driver waits for the interrupt transfer, will fix the problem with ehci. However, I expect that the transfer is slightly slower then with ehci, compared to kernel 3.10. regards Marcus == Proposed fix (workaround) diff --git a/drivers/staging/rts5139/ rts51x_transport.c b/drivers/staging/rts5139/rts51x_transport.c index c172f4a..c4ede32 100644 --- a/drivers/staging/rts5139/rts51x_transport.c +++ b/drivers/staging/rts5139/rts51x_transport.c @@ -640,7 +640,7 @@ int rts51x_get_epc_status(struct rts51x_chip *chip, u16 *status) usb_fill_int_urb(chip-usb-intr_urb, chip-usb-pusb_dev, pipe, status, 2, urb_done_completion, urb_done, 10); - result = rts51x_msg_common(chip, chip-usb-intr_urb, 100); + result = rts51x_msg_common(chip, chip-usb-intr_urb, 500); return interpret_urb_result(chip, pipe, 2, result, chip-usb-intr_urb-actual_length); == === Patch that went into kernel 3.11 Using correct transfer interval as specified by the USB endpoint when doing the interrupt transfer fixes the warning printed by xhci USB core on every transfer that resulted in spamming xhci_queue_intr_tx: 74 callbacks suppressed to syslog every 5 seconds. Signed-off-by: Marcus Overhagen marcus.overha...@gmail.com --- drivers/staging/rts5139/ rts51x_transport.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rts5139/rts51x_transport.c b/drivers/staging/rts5139/rts51x_transport.c index c573618..c172f4a 100644 --- a/drivers/staging/rts5139/rts51x_transport.c +++ b/drivers/staging/rts5139/rts51x_transport.c @@ -635,10 +635,10 @@ int rts51x_get_epc_status(struct rts51x_chip *chip, u16 *status) ep = chip-usb-pusb_dev-ep_in[usb_pipeendpoint(pipe)]; /* fill and submit the URB */ - /* We set interval to 1 here, so the polling interval is controlled -* by our polling thread */ + /* Set interval to 10 here to match the endpoint descriptor, +* the polling interval is controlled by the polling thread */ usb_fill_int_urb(chip-usb-intr_urb, chip-usb-pusb_dev, pipe, -status, 2, urb_done_completion, urb_done, 1); +status, 2, urb_done_completion, urb_done, 10); result = rts51x_msg_common(chip, chip-usb-intr_urb, 100); === -- 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: Scheduling of interrupt transfer delayed on ehci when interval not 1?
On Tue, 15 Oct 2013, Marcus Overhagen wrote: Hello, I made a change to the rts5139 driver that got included in kernel 3.11 (see second patch at end of this email), but Lutz Vieweg reported that the patch causes issues for him, because the driver falsely detects that the SD card is no longer present after transfer of a few 100 MBs. Why does the driver make this mistake? I do not have this issue with xhci. He is using ehci. The USB endpoint specifies a transfer interval of 10. The rts5139 Does the device connect at high speed (480 Mb/s)? driver uses the interrupt transfer to infrequently poll for card presence, but doesn't queue multiple urbs for periodic transfers. The issue seems to be a difference in how early the (first) interrupt transfer is scheduled by xhci and ehci when the interval specified in the urb is not 1. With ehci it seems to be delayed when the interval is not 1. With xhci you get warning messages in syslog if interval is not 10. My USB knowledge is too limited to properly fix this in xhci or ehci hcd. What needs to be fixed? It sounds like xhci-hcd and ehci-hcd are working correctly and the problem is in the rts5139 driver. Can somebody help me? what is the correct fix for this problem? It is possible that the following patch, that increases the timeout the driver waits for the interrupt transfer, will fix the problem with ehci. However, I expect that the transfer is slightly slower then with ehci, compared to kernel 3.10. bInterval = 10 means the polling period is 64 ms (for a high-speed device). So a timeout of 100 ms should be adequate -- provided the device always sends data over the interrupt endpoint without any further delay. 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: Scheduling of interrupt transfer delayed on ehci when interval not 1?
On 10/15/2013 06:07 PM, Alan Stern wrote: The USB endpoint specifies a transfer interval of 10. The rts5139 Does the device connect at high speed (480 Mb/s)? I can say that the rts5139 card reader in my laptop does use the 480 MBit/s rate. (I don't know whether there are derivatives of that reader that would support higher rates.) Regards, Lutz Vieweg -- 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: Scheduling of interrupt transfer delayed on ehci when interval not 1?
On Tue, Oct 15, 2013 at 6:07 PM, Alan Stern st...@rowland.harvard.edu wrote: Why does the driver make this mistake? My initial assumption was wrong, the driver doesn't infrequently poll, but does so more often. I was misled by the confusing source. However, I now made usbmon traces and analyzed them with LibreOffice. During data transfer, the driver does a interrupt transfer about 48ms after the last one, and has to wait about 15ms for the result. But every 40 transfers, it executes 3 transfers without waiting inbetween and has to wait 63ms for the result. This is with transfer interval set to 10 on xhci. I also compiled the driver with transfer interval set to 1 (the original setting before my patch [1]), but the result is similar, an interrupt transfer every 44ms, and waiting of 19ms for the result. I don't have ehci hardware to test it. When the URB completition callback is executed, it calles complete(), while the driver is using wait_for_completion_interruptible_timeout() for this signal with 100ms timeout (originally that was 50ms but I changed it in patch [2] to make it work with xhci) This function seems to timeout on ehci hardware after about 700MB to 7GB transfered. I guess that the thread isn't scheduled fast enough under load, although the USB transfer was successful. Does the device connect at high speed (480 Mb/s)? Yes, even with xhci it is only using 480Mb/s. What needs to be fixed? It sounds like xhci-hcd and ehci-hcd are working correctly and the problem is in the rts5139 driver. After looking at the usbmon traces, i have to agree. bInterval = 10 means the polling period is 64 ms (for a high-speed device). So a timeout of 100 ms should be adequate -- provided the device always sends data over the interrupt endpoint without any further delay. What i do not understand: with ehci hardware, the driver works when interval in the urb is set to 1 and the timeout is 50ms. With xhci, the urb appears to be scheduled not more often then every 64ms even if the interval in the urb is set to 1. I'm just looking for the correct solution for this issue. regards Marcus below some more info: [1] patch I made to get rid of syslog warnings because of wrong interval with xhci (that broke it for ehci hardware) https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6441a57887281106ed01222c2b0561ab25f77212 [2] patch I made to get it working on xhci (increasing timeout from 50 to 100): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c5c141dfe737706d8bd57f40b4a9a8818c5ce4der T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 P: Vendor=0bda ProdID=0129 Rev=39.60 S: Manufacturer=Generic S: Product=USB2.0-CRW S: SerialNumber=2010020139600 C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=50 Driver=rts5139 E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 3 Ivl=64ms root@goetterdaemmerung:/home/marcus/linux# lsusb -v -s 3:2 Bus 003 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x0bda Realtek Semiconductor Corp. idProduct 0x0129 bcdDevice 39.60 iManufacturer 1 Generic iProduct2 USB2.0-CRW iSerial 3 2010020139600 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 CARD READER bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 6 bInterfaceProtocol 80 iInterface 5 Bulk-In, Bulk-Out, Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2
