Re: howto debug xhci driver?
On Mon, Apr 23, 2018 at 07:21:12PM +0530, Tushar Nimkar wrote: > Hi, > > On 2018-04-23 18:58, Bin Liu wrote: > >On Mon, Apr 23, 2018 at 11:14:55AM +0530, Tushar Nimkar wrote: > >>On 2018-04-21 00:03, Bin Liu wrote: > >>>Hi, > >>> > >>>On Tue, Mar 20, 2018 at 02:28:00PM -0700, Paul Zimmerman wrote: > >>>>Forgot to CC linux-usb. > >>>> > >>>> > >>>> Forwarded Message > >>>>Subject: Re: howto debug xhci driver? > >>>>Date: Tue, 20 Mar 2018 13:56:21 -0700 > >>>>From: Paul Zimmerman > >>>>To: Bin Liu > >>>>CC: Felipe Balbi > >>>> > >>>>Hi, > >>>> > >>>>Bin Liu writes: > >>>>>>Bin Liu writes: > >>>>>>>>>>>>BTY, the issue I am trying to debug is when reading > >>>>>>>>>>>>bulk IN data from a USB2.0 device, if the device > >>>>>>>>>>>>doesn't have data to transmit and NAKs the IN packet, > >>>>>>>>>>>>after 4 pairs of IN-NAK transactions, xhci stops > >>>>>>>>>>>>sending further IN tokens until the next SOF, which > >>>>>>>>>>>>leaves ~90us gape on the bus. > >>>>>>>>>>>> > >>>>>>>>>>>>But when reading data from a USB2.0 thumb drive, this > >>>>>>>>>>>>issue doesn't happen, even if the device NAKs the IN > >>>>>>>>>>>>tokens, xhci still keeps sending IN tokens, which is > >>>>>>>>>>>>way more than 4 pairs of IN-NAK transactions. > >>>>>>>>>>> > >>>>>>>>>>>Thumb drive has Bulk endpoints, what is the other > >>>>>>>>>>>device's transfer type? > >>>>>>>>>> > >>>>>>>>>>It is bulk too. I asked for device descriptors. This is a > >>>>>>>>>>remote debug effort for me, I don't have that device... > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>Any one has a clue on what causes xhci to stop sending > >>>>>>>>>>>>IN tokens after the device NAK'd 4 times? > >>>>>>>>> > >>>>>>>>>By accident, I reproduced the issue if addng a hub in the > >>>>>>>>>middle... any comments about why a hub changes this xhci > >>>>>>>>>behavior is appreciated. > >>>>>>>> > >>>>>>>>none off the top of my head. Maybe Mathias can suggest > >>>>>>>>something. > >>>>>>> > >>>>>>>The issue seems to be not related to how many bulk IN-NAK pairs > >>>>>>>before host stops sending IN token, but the host stops IN token > >>>>>>>if 1) the device ever NAK'd an bulk IN token, and 2) there is > >>>>>>>about 90~100us left to the next SOF. Then all the rest of > >>>>>>>bandwidth is wasted. > >>>>>>> > >>>>>>>Is it about xhci bandwidth schduling? /me started reading... > >>>>>> > >>>>>>is this AM4 or AM5? Perhaps go after Synopsys' known errata list? > >>>>> > >>>>>I see the issue on both AM4 & AM5. I don't have access to the > >>>>>errata list, I guess I should talk to TI internal for the list? > >>>> > >>>>I have a hazy recollection of something like this being a "feature" of > >>>>the Synopsys core, to cut down on the excessive number of IN-NAK > >>>>transactions you can sometimes get on the USB bus. So yep, you > >>>>should talk to your Synopsys guy about this. > >>> > >>>Thanks for the information. We have been talking to Synopsis for this > >>>issue, the progress is slow, one of the reasons is that the DWC3 > >>>version > >>>is very old :( > >>Bin, What is the version no? I have seen similar thing but on USB3.0 > > > >On multiple versions: from 2.02a to 2.60a. > suggest you to check errata list if not. Yeah, stuck at here right now - too slow to get a copy of the errata :( > > > >>with dwc3 3.00a > > > >Do you mean you only see the problem in super-speed but not high-speed > >with 3.00a? > yes so far.. > > > >>May I know how you confirmed/debug missing IN-ACK? > > > >Using bus protocol analyzer to capture bus traces. However my > >issue is not > >about missing IN-ACK, but IN-NAK - the host stops sending IN tokens too > >early if the device NAK'd previous IN packets. > > > >Please confirm you mean IN-NAK instead in your case? > it is IN-ACK, ss device send ERDY there should be IN-ACK saying NumP > > 0 from host :) Sounds like we face two different issues then :) Regards, -Bin. -- 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: howto debug xhci driver?
Hi, On 2018-04-23 18:58, Bin Liu wrote: On Mon, Apr 23, 2018 at 11:14:55AM +0530, Tushar Nimkar wrote: On 2018-04-21 00:03, Bin Liu wrote: >Hi, > >On Tue, Mar 20, 2018 at 02:28:00PM -0700, Paul Zimmerman wrote: >>Forgot to CC linux-usb. >> >> >> Forwarded Message ---- >>Subject: Re: howto debug xhci driver? >>Date: Tue, 20 Mar 2018 13:56:21 -0700 >>From: Paul Zimmerman >>To: Bin Liu >>CC: Felipe Balbi >> >>Hi, >> >>Bin Liu writes: >>>>Bin Liu writes: >>>>>>>>>>BTY, the issue I am trying to debug is when reading >>>>>>>>>>bulk IN data from a USB2.0 device, if the device >>>>>>>>>>doesn't have data to transmit and NAKs the IN packet, >>>>>>>>>>after 4 pairs of IN-NAK transactions, xhci stops >>>>>>>>>>sending further IN tokens until the next SOF, which >>>>>>>>>>leaves ~90us gape on the bus. >>>>>>>>>> >>>>>>>>>>But when reading data from a USB2.0 thumb drive, this >>>>>>>>>>issue doesn't happen, even if the device NAKs the IN >>>>>>>>>>tokens, xhci still keeps sending IN tokens, which is >>>>>>>>>>way more than 4 pairs of IN-NAK transactions. >>>>>>>>> >>>>>>>>>Thumb drive has Bulk endpoints, what is the other >>>>>>>>>device's transfer type? >>>>>>>> >>>>>>>>It is bulk too. I asked for device descriptors. This is a >>>>>>>>remote debug effort for me, I don't have that device... >>>>>>>> >>>>>>>>> >>>>>>>>>>Any one has a clue on what causes xhci to stop sending >>>>>>>>>>IN tokens after the device NAK'd 4 times? >>>>>>> >>>>>>>By accident, I reproduced the issue if addng a hub in the >>>>>>>middle... any comments about why a hub changes this xhci >>>>>>>behavior is appreciated. >>>>>> >>>>>>none off the top of my head. Maybe Mathias can suggest >>>>>>something. >>>>> >>>>>The issue seems to be not related to how many bulk IN-NAK pairs >>>>>before host stops sending IN token, but the host stops IN token >>>>>if 1) the device ever NAK'd an bulk IN token, and 2) there is >>>>>about 90~100us left to the next SOF. Then all the rest of >>>>>bandwidth is wasted. >>>>> >>>>>Is it about xhci bandwidth schduling? /me started reading... >>>> >>>>is this AM4 or AM5? Perhaps go after Synopsys' known errata list? >>> >>>I see the issue on both AM4 & AM5. I don't have access to the >>>errata list, I guess I should talk to TI internal for the list? >> >>I have a hazy recollection of something like this being a "feature" of >>the Synopsys core, to cut down on the excessive number of IN-NAK >>transactions you can sometimes get on the USB bus. So yep, you >>should talk to your Synopsys guy about this. > >Thanks for the information. We have been talking to Synopsis for this >issue, the progress is slow, one of the reasons is that the DWC3 >version >is very old :( Bin, What is the version no? I have seen similar thing but on USB3.0 On multiple versions: from 2.02a to 2.60a. suggest you to check errata list if not. with dwc3 3.00a Do you mean you only see the problem in super-speed but not high-speed with 3.00a? yes so far.. May I know how you confirmed/debug missing IN-ACK? Using bus protocol analyzer to capture bus traces. However my issue is not about missing IN-ACK, but IN-NAK - the host stops sending IN tokens too early if the device NAK'd previous IN packets. Please confirm you mean IN-NAK instead in your case? it is IN-ACK, ss device send ERDY there should be IN-ACK saying NumP > 0 from host :) Regards, -Bin. -- 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 -- Best Regards, Tushar R Nimkar QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: howto debug xhci driver?
On Mon, Apr 23, 2018 at 11:14:55AM +0530, Tushar Nimkar wrote: > On 2018-04-21 00:03, Bin Liu wrote: > >Hi, > > > >On Tue, Mar 20, 2018 at 02:28:00PM -0700, Paul Zimmerman wrote: > >>Forgot to CC linux-usb. > >> > >> > >>---- Forwarded Message > >>Subject: Re: howto debug xhci driver? > >>Date: Tue, 20 Mar 2018 13:56:21 -0700 > >>From: Paul Zimmerman > >>To: Bin Liu > >>CC: Felipe Balbi > >> > >>Hi, > >> > >>Bin Liu writes: > >>>>Bin Liu writes: > >>>>>>>>>>BTY, the issue I am trying to debug is when reading > >>>>>>>>>>bulk IN data from a USB2.0 device, if the device > >>>>>>>>>>doesn't have data to transmit and NAKs the IN packet, > >>>>>>>>>>after 4 pairs of IN-NAK transactions, xhci stops > >>>>>>>>>>sending further IN tokens until the next SOF, which > >>>>>>>>>>leaves ~90us gape on the bus. > >>>>>>>>>> > >>>>>>>>>>But when reading data from a USB2.0 thumb drive, this > >>>>>>>>>>issue doesn't happen, even if the device NAKs the IN > >>>>>>>>>>tokens, xhci still keeps sending IN tokens, which is > >>>>>>>>>>way more than 4 pairs of IN-NAK transactions. > >>>>>>>>> > >>>>>>>>>Thumb drive has Bulk endpoints, what is the other > >>>>>>>>>device's transfer type? > >>>>>>>> > >>>>>>>>It is bulk too. I asked for device descriptors. This is a > >>>>>>>>remote debug effort for me, I don't have that device... > >>>>>>>> > >>>>>>>>> > >>>>>>>>>>Any one has a clue on what causes xhci to stop sending > >>>>>>>>>>IN tokens after the device NAK'd 4 times? > >>>>>>> > >>>>>>>By accident, I reproduced the issue if addng a hub in the > >>>>>>>middle... any comments about why a hub changes this xhci > >>>>>>>behavior is appreciated. > >>>>>> > >>>>>>none off the top of my head. Maybe Mathias can suggest > >>>>>>something. > >>>>> > >>>>>The issue seems to be not related to how many bulk IN-NAK pairs > >>>>>before host stops sending IN token, but the host stops IN token > >>>>>if 1) the device ever NAK'd an bulk IN token, and 2) there is > >>>>>about 90~100us left to the next SOF. Then all the rest of > >>>>>bandwidth is wasted. > >>>>> > >>>>>Is it about xhci bandwidth schduling? /me started reading... > >>>> > >>>>is this AM4 or AM5? Perhaps go after Synopsys' known errata list? > >>> > >>>I see the issue on both AM4 & AM5. I don't have access to the > >>>errata list, I guess I should talk to TI internal for the list? > >> > >>I have a hazy recollection of something like this being a "feature" of > >>the Synopsys core, to cut down on the excessive number of IN-NAK > >>transactions you can sometimes get on the USB bus. So yep, you > >>should talk to your Synopsys guy about this. > > > >Thanks for the information. We have been talking to Synopsis for this > >issue, the progress is slow, one of the reasons is that the DWC3 > >version > >is very old :( > Bin, What is the version no? I have seen similar thing but on USB3.0 On multiple versions: from 2.02a to 2.60a. > with dwc3 3.00a Do you mean you only see the problem in super-speed but not high-speed with 3.00a? > May I know how you confirmed/debug missing IN-ACK? Using bus protocol analyzer to capture bus traces. However my issue is not about missing IN-ACK, but IN-NAK - the host stops sending IN tokens too early if the device NAK'd previous IN packets. Please confirm you mean IN-NAK instead in your case? Regards, -Bin. -- 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: howto debug xhci driver?
On 2018-04-21 00:03, Bin Liu wrote: Hi, On Tue, Mar 20, 2018 at 02:28:00PM -0700, Paul Zimmerman wrote: Forgot to CC linux-usb. Forwarded Message Subject: Re: howto debug xhci driver? Date: Tue, 20 Mar 2018 13:56:21 -0700 From: Paul Zimmerman To: Bin Liu CC: Felipe Balbi Hi, Bin Liu writes: >>Bin Liu writes: >>>>>>>>BTY, the issue I am trying to debug is when reading >>>>>>>>bulk IN data from a USB2.0 device, if the device >>>>>>>>doesn't have data to transmit and NAKs the IN packet, >>>>>>>>after 4 pairs of IN-NAK transactions, xhci stops >>>>>>>>sending further IN tokens until the next SOF, which >>>>>>>>leaves ~90us gape on the bus. >>>>>>>> >>>>>>>>But when reading data from a USB2.0 thumb drive, this >>>>>>>>issue doesn't happen, even if the device NAKs the IN >>>>>>>>tokens, xhci still keeps sending IN tokens, which is >>>>>>>>way more than 4 pairs of IN-NAK transactions. >>>>>>> >>>>>>>Thumb drive has Bulk endpoints, what is the other >>>>>>>device's transfer type? >>>>>> >>>>>>It is bulk too. I asked for device descriptors. This is a >>>>>>remote debug effort for me, I don't have that device... >>>>>> >>>>>>> >>>>>>>>Any one has a clue on what causes xhci to stop sending >>>>>>>>IN tokens after the device NAK'd 4 times? >>>>> >>>>>By accident, I reproduced the issue if addng a hub in the >>>>>middle... any comments about why a hub changes this xhci >>>>>behavior is appreciated. >>>> >>>>none off the top of my head. Maybe Mathias can suggest >>>>something. >>> >>>The issue seems to be not related to how many bulk IN-NAK pairs >>>before host stops sending IN token, but the host stops IN token >>>if 1) the device ever NAK'd an bulk IN token, and 2) there is >>>about 90~100us left to the next SOF. Then all the rest of >>>bandwidth is wasted. >>> >>>Is it about xhci bandwidth schduling? /me started reading... >> >>is this AM4 or AM5? Perhaps go after Synopsys' known errata list? > >I see the issue on both AM4 & AM5. I don't have access to the >errata list, I guess I should talk to TI internal for the list? I have a hazy recollection of something like this being a "feature" of the Synopsys core, to cut down on the excessive number of IN-NAK transactions you can sometimes get on the USB bus. So yep, you should talk to your Synopsys guy about this. Thanks for the information. We have been talking to Synopsis for this issue, the progress is slow, one of the reasons is that the DWC3 version is very old :( Bin, What is the version no? I have seen similar thing but on USB3.0 with dwc3 3.00a May I know how you confirmed/debug missing IN-ACK? However, I just realized that in this case even though DWC3 in host mode doesn't fully utilize the bus bandwidth, it doesn't violate any of the USB Specs, as the Specs don't define flow control for bulk IN transfer. The USB device shouldn't use bulk protocol at the first place if it has bus bandwidth requirements. Isoch probably is a better choice. I will check if there is anything can be done on the USB device side to solve the problem. Thanks all for the help. Regards, -Bin. -- 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 -- Best Regards, Tushar R Nimkar QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: howto debug xhci driver?
Hi, On Tue, Mar 20, 2018 at 02:28:00PM -0700, Paul Zimmerman wrote: > Forgot to CC linux-usb. > > > Forwarded Message > Subject: Re: howto debug xhci driver? > Date: Tue, 20 Mar 2018 13:56:21 -0700 > From: Paul Zimmerman > To: Bin Liu > CC: Felipe Balbi > > Hi, > > Bin Liu writes: > >>Bin Liu writes: > >>>>>>>>BTY, the issue I am trying to debug is when reading > >>>>>>>>bulk IN data from a USB2.0 device, if the device > >>>>>>>>doesn't have data to transmit and NAKs the IN packet, > >>>>>>>>after 4 pairs of IN-NAK transactions, xhci stops > >>>>>>>>sending further IN tokens until the next SOF, which > >>>>>>>>leaves ~90us gape on the bus. > >>>>>>>> > >>>>>>>>But when reading data from a USB2.0 thumb drive, this > >>>>>>>>issue doesn't happen, even if the device NAKs the IN > >>>>>>>>tokens, xhci still keeps sending IN tokens, which is > >>>>>>>>way more than 4 pairs of IN-NAK transactions. > >>>>>>> > >>>>>>>Thumb drive has Bulk endpoints, what is the other > >>>>>>>device's transfer type? > >>>>>> > >>>>>>It is bulk too. I asked for device descriptors. This is a > >>>>>>remote debug effort for me, I don't have that device... > >>>>>> > >>>>>>> > >>>>>>>>Any one has a clue on what causes xhci to stop sending > >>>>>>>>IN tokens after the device NAK'd 4 times? > >>>>> > >>>>>By accident, I reproduced the issue if addng a hub in the > >>>>>middle... any comments about why a hub changes this xhci > >>>>>behavior is appreciated. > >>>> > >>>>none off the top of my head. Maybe Mathias can suggest > >>>>something. > >>> > >>>The issue seems to be not related to how many bulk IN-NAK pairs > >>>before host stops sending IN token, but the host stops IN token > >>>if 1) the device ever NAK'd an bulk IN token, and 2) there is > >>>about 90~100us left to the next SOF. Then all the rest of > >>>bandwidth is wasted. > >>> > >>>Is it about xhci bandwidth schduling? /me started reading... > >> > >>is this AM4 or AM5? Perhaps go after Synopsys' known errata list? > > > >I see the issue on both AM4 & AM5. I don't have access to the > >errata list, I guess I should talk to TI internal for the list? > > I have a hazy recollection of something like this being a "feature" of > the Synopsys core, to cut down on the excessive number of IN-NAK > transactions you can sometimes get on the USB bus. So yep, you > should talk to your Synopsys guy about this. Thanks for the information. We have been talking to Synopsis for this issue, the progress is slow, one of the reasons is that the DWC3 version is very old :( However, I just realized that in this case even though DWC3 in host mode doesn't fully utilize the bus bandwidth, it doesn't violate any of the USB Specs, as the Specs don't define flow control for bulk IN transfer. The USB device shouldn't use bulk protocol at the first place if it has bus bandwidth requirements. Isoch probably is a better choice. I will check if there is anything can be done on the USB device side to solve the problem. Thanks all for the help. Regards, -Bin. -- 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: howto debug xhci driver?
Forgot to CC linux-usb. Forwarded Message Subject: Re: howto debug xhci driver? Date: Tue, 20 Mar 2018 13:56:21 -0700 From: Paul Zimmerman To: Bin Liu CC: Felipe Balbi Hi, Bin Liu writes: Bin Liu writes: BTY, the issue I am trying to debug is when reading bulk IN data from a USB2.0 device, if the device doesn't have data to transmit and NAKs the IN packet, after 4 pairs of IN-NAK transactions, xhci stops sending further IN tokens until the next SOF, which leaves ~90us gape on the bus. But when reading data from a USB2.0 thumb drive, this issue doesn't happen, even if the device NAKs the IN tokens, xhci still keeps sending IN tokens, which is way more than 4 pairs of IN-NAK transactions. Thumb drive has Bulk endpoints, what is the other device's transfer type? It is bulk too. I asked for device descriptors. This is a remote debug effort for me, I don't have that device... Any one has a clue on what causes xhci to stop sending IN tokens after the device NAK'd 4 times? By accident, I reproduced the issue if addng a hub in the middle... any comments about why a hub changes this xhci behavior is appreciated. none off the top of my head. Maybe Mathias can suggest something. The issue seems to be not related to how many bulk IN-NAK pairs before host stops sending IN token, but the host stops IN token if 1) the device ever NAK'd an bulk IN token, and 2) there is about 90~100us left to the next SOF. Then all the rest of bandwidth is wasted. Is it about xhci bandwidth schduling? /me started reading... is this AM4 or AM5? Perhaps go after Synopsys' known errata list? I see the issue on both AM4 & AM5. I don't have access to the errata list, I guess I should talk to TI internal for the list? I have a hazy recollection of something like this being a "feature" of the Synopsys core, to cut down on the excessive number of IN-NAK transactions you can sometimes get on the USB bus. So yep, you should talk to your Synopsys guy about this. -- Paul -- 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: howto debug xhci driver?
On Tue, Mar 20, 2018 at 08:32:19AM -0500, Bin Liu wrote: > On Tue, Mar 20, 2018 at 09:14:12AM +0200, Felipe Balbi wrote: > > > > Hi, > > > > Bin Liu writes: > > > On Mon, Mar 05, 2018 at 01:21:42PM -0600, Bin Liu wrote: > > >> On Mon, Mar 05, 2018 at 10:16:49AM +0200, Felipe Balbi wrote: > > >> > > > >> > Hi, > > >> > > > >> > Bin Liu writes: > > >> > > I am relatively new to xhci and its driver. I am trying to get a xhci > > >> > > driver runtime log to understand how it handles usb transactions, > > >> > > but I > > >> > > don't get much information with dynamic debug (module xhci_hcd) or > > >> > > enabling xhci trace events. Is there any other methods you guys use > > >> > > to > > >> > > debug xhci driver? > > >> > > > >> > tracepoints, the best thing since sliced bread ;-) > > >> > > >> I know, but I didn't get any trace log in bulk IN transfers :( > > >> It turns out - I was on v4.9, which doesn't have much tracepoints. Now I > > >> see you added more since v4.11. I will try to move to the latest kernel. > > >> > > >> > > > >> > > BTY, the issue I am trying to debug is when reading bulk IN data > > >> > > from a > > >> > > USB2.0 device, if the device doesn't have data to transmit and NAKs > > >> > > the > > >> > > IN packet, after 4 pairs of IN-NAK transactions, xhci stops sending > > >> > > further IN tokens until the next SOF, which leaves ~90us gape on the > > >> > > bus. > > >> > > > > >> > > But when reading data from a USB2.0 thumb drive, this issue doesn't > > >> > > happen, even if the device NAKs the IN tokens, xhci still keeps > > >> > > sending > > >> > > IN tokens, which is way more than 4 pairs of IN-NAK transactions. > > >> > > > >> > Thumb drive has Bulk endpoints, what is the other device's transfer > > >> > type? > > >> > > >> It is bulk too. I asked for device descriptors. This is a remote debug > > >> effort for me, I don't have that device... > > >> > > >> > > > >> > > Any one has a clue on what causes xhci to stop sending IN tokens > > >> > > after > > >> > > the device NAK'd 4 times? > > > > > > By accident, I reproduced the issue if addng a hub in the middle... > > > any comments about why a hub changes this xhci behavior is appreciated. > > > > none off the top of my head. Maybe Mathias can suggest something. > > The issue seems to be not related to how many bulk IN-NAK pairs before > host stops sending IN token, but the host stops IN token if 1) the > device ever NAK'd an bulk IN token, and 2) there is about 90~100us left > to the next SOF. Then all the rest of bandwidth is wasted. > > Is it about xhci bandwidth schduling? /me started reading... Reproduced the issue with the sourcesink+hid gadget, which adds an interrupt ep on the bus, so this appears to be bandwidth scheduling problem... Regards, -Bin. -- 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: howto debug xhci driver?
Hi, Bin Liu writes: >> Bin Liu writes: >> >> >> > > BTY, the issue I am trying to debug is when reading bulk IN data >> >> >> > > from a >> >> >> > > USB2.0 device, if the device doesn't have data to transmit and >> >> >> > > NAKs the >> >> >> > > IN packet, after 4 pairs of IN-NAK transactions, xhci stops sending >> >> >> > > further IN tokens until the next SOF, which leaves ~90us gape on >> >> >> > > the >> >> >> > > bus. >> >> >> > > >> >> >> > > But when reading data from a USB2.0 thumb drive, this issue doesn't >> >> >> > > happen, even if the device NAKs the IN tokens, xhci still keeps >> >> >> > > sending >> >> >> > > IN tokens, which is way more than 4 pairs of IN-NAK transactions. >> >> >> > >> >> >> > Thumb drive has Bulk endpoints, what is the other device's transfer >> >> >> > type? >> >> >> >> >> >> It is bulk too. I asked for device descriptors. This is a remote debug >> >> >> effort for me, I don't have that device... >> >> >> >> >> >> > >> >> >> > > Any one has a clue on what causes xhci to stop sending IN tokens >> >> >> > > after >> >> >> > > the device NAK'd 4 times? >> >> > >> >> > By accident, I reproduced the issue if addng a hub in the middle... >> >> > any comments about why a hub changes this xhci behavior is appreciated. >> >> >> >> none off the top of my head. Maybe Mathias can suggest something. >> > >> > The issue seems to be not related to how many bulk IN-NAK pairs before >> > host stops sending IN token, but the host stops IN token if 1) the >> > device ever NAK'd an bulk IN token, and 2) there is about 90~100us left >> > to the next SOF. Then all the rest of bandwidth is wasted. >> > >> > Is it about xhci bandwidth schduling? /me started reading... >> >> is this AM4 or AM5? Perhaps go after Synopsys' known errata list? > > I see the issue on both AM4 & AM5. I don't have access to the errata > list, I guess I should talk to TI internal for the list? Right, your HW folks should have a pointer. Dave K may be a good starting contact ;-) -- balbi signature.asc Description: PGP signature
Re: howto debug xhci driver?
On Tue, Mar 20, 2018 at 03:34:16PM +0200, Felipe Balbi wrote: > > Hi, > > Bin Liu writes: > >> >> > > BTY, the issue I am trying to debug is when reading bulk IN data > >> >> > > from a > >> >> > > USB2.0 device, if the device doesn't have data to transmit and NAKs > >> >> > > the > >> >> > > IN packet, after 4 pairs of IN-NAK transactions, xhci stops sending > >> >> > > further IN tokens until the next SOF, which leaves ~90us gape on the > >> >> > > bus. > >> >> > > > >> >> > > But when reading data from a USB2.0 thumb drive, this issue doesn't > >> >> > > happen, even if the device NAKs the IN tokens, xhci still keeps > >> >> > > sending > >> >> > > IN tokens, which is way more than 4 pairs of IN-NAK transactions. > >> >> > > >> >> > Thumb drive has Bulk endpoints, what is the other device's transfer > >> >> > type? > >> >> > >> >> It is bulk too. I asked for device descriptors. This is a remote debug > >> >> effort for me, I don't have that device... > >> >> > >> >> > > >> >> > > Any one has a clue on what causes xhci to stop sending IN tokens > >> >> > > after > >> >> > > the device NAK'd 4 times? > >> > > >> > By accident, I reproduced the issue if addng a hub in the middle... > >> > any comments about why a hub changes this xhci behavior is appreciated. > >> > >> none off the top of my head. Maybe Mathias can suggest something. > > > > The issue seems to be not related to how many bulk IN-NAK pairs before > > host stops sending IN token, but the host stops IN token if 1) the > > device ever NAK'd an bulk IN token, and 2) there is about 90~100us left > > to the next SOF. Then all the rest of bandwidth is wasted. > > > > Is it about xhci bandwidth schduling? /me started reading... > > is this AM4 or AM5? Perhaps go after Synopsys' known errata list? I see the issue on both AM4 & AM5. I don't have access to the errata list, I guess I should talk to TI internal for the list? Regards, -Bin. -- 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: howto debug xhci driver?
Hi, Bin Liu writes: >> >> > > BTY, the issue I am trying to debug is when reading bulk IN data from >> >> > > a >> >> > > USB2.0 device, if the device doesn't have data to transmit and NAKs >> >> > > the >> >> > > IN packet, after 4 pairs of IN-NAK transactions, xhci stops sending >> >> > > further IN tokens until the next SOF, which leaves ~90us gape on the >> >> > > bus. >> >> > > >> >> > > But when reading data from a USB2.0 thumb drive, this issue doesn't >> >> > > happen, even if the device NAKs the IN tokens, xhci still keeps >> >> > > sending >> >> > > IN tokens, which is way more than 4 pairs of IN-NAK transactions. >> >> > >> >> > Thumb drive has Bulk endpoints, what is the other device's transfer >> >> > type? >> >> >> >> It is bulk too. I asked for device descriptors. This is a remote debug >> >> effort for me, I don't have that device... >> >> >> >> > >> >> > > Any one has a clue on what causes xhci to stop sending IN tokens after >> >> > > the device NAK'd 4 times? >> > >> > By accident, I reproduced the issue if addng a hub in the middle... >> > any comments about why a hub changes this xhci behavior is appreciated. >> >> none off the top of my head. Maybe Mathias can suggest something. > > The issue seems to be not related to how many bulk IN-NAK pairs before > host stops sending IN token, but the host stops IN token if 1) the > device ever NAK'd an bulk IN token, and 2) there is about 90~100us left > to the next SOF. Then all the rest of bandwidth is wasted. > > Is it about xhci bandwidth schduling? /me started reading... is this AM4 or AM5? Perhaps go after Synopsys' known errata list? -- balbi signature.asc Description: PGP signature
Re: howto debug xhci driver?
On Tue, Mar 20, 2018 at 09:14:12AM +0200, Felipe Balbi wrote: > > Hi, > > Bin Liu writes: > > On Mon, Mar 05, 2018 at 01:21:42PM -0600, Bin Liu wrote: > >> On Mon, Mar 05, 2018 at 10:16:49AM +0200, Felipe Balbi wrote: > >> > > >> > Hi, > >> > > >> > Bin Liu writes: > >> > > I am relatively new to xhci and its driver. I am trying to get a xhci > >> > > driver runtime log to understand how it handles usb transactions, but I > >> > > don't get much information with dynamic debug (module xhci_hcd) or > >> > > enabling xhci trace events. Is there any other methods you guys use to > >> > > debug xhci driver? > >> > > >> > tracepoints, the best thing since sliced bread ;-) > >> > >> I know, but I didn't get any trace log in bulk IN transfers :( > >> It turns out - I was on v4.9, which doesn't have much tracepoints. Now I > >> see you added more since v4.11. I will try to move to the latest kernel. > >> > >> > > >> > > BTY, the issue I am trying to debug is when reading bulk IN data from a > >> > > USB2.0 device, if the device doesn't have data to transmit and NAKs the > >> > > IN packet, after 4 pairs of IN-NAK transactions, xhci stops sending > >> > > further IN tokens until the next SOF, which leaves ~90us gape on the > >> > > bus. > >> > > > >> > > But when reading data from a USB2.0 thumb drive, this issue doesn't > >> > > happen, even if the device NAKs the IN tokens, xhci still keeps sending > >> > > IN tokens, which is way more than 4 pairs of IN-NAK transactions. > >> > > >> > Thumb drive has Bulk endpoints, what is the other device's transfer type? > >> > >> It is bulk too. I asked for device descriptors. This is a remote debug > >> effort for me, I don't have that device... > >> > >> > > >> > > Any one has a clue on what causes xhci to stop sending IN tokens after > >> > > the device NAK'd 4 times? > > > > By accident, I reproduced the issue if addng a hub in the middle... > > any comments about why a hub changes this xhci behavior is appreciated. > > none off the top of my head. Maybe Mathias can suggest something. The issue seems to be not related to how many bulk IN-NAK pairs before host stops sending IN token, but the host stops IN token if 1) the device ever NAK'd an bulk IN token, and 2) there is about 90~100us left to the next SOF. Then all the rest of bandwidth is wasted. Is it about xhci bandwidth schduling? /me started reading... > > >> > tracepoints, please :-) > > > > I will get tracepoints for cases w/ and w/o a hub. Both tracepoints logs are the same, only a few lines - enqueue, dequeue... Regards, -Bin. -- 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: howto debug xhci driver?
Hi, Bin Liu writes: > On Mon, Mar 05, 2018 at 01:21:42PM -0600, Bin Liu wrote: >> On Mon, Mar 05, 2018 at 10:16:49AM +0200, Felipe Balbi wrote: >> > >> > Hi, >> > >> > Bin Liu writes: >> > > I am relatively new to xhci and its driver. I am trying to get a xhci >> > > driver runtime log to understand how it handles usb transactions, but I >> > > don't get much information with dynamic debug (module xhci_hcd) or >> > > enabling xhci trace events. Is there any other methods you guys use to >> > > debug xhci driver? >> > >> > tracepoints, the best thing since sliced bread ;-) >> >> I know, but I didn't get any trace log in bulk IN transfers :( >> It turns out - I was on v4.9, which doesn't have much tracepoints. Now I >> see you added more since v4.11. I will try to move to the latest kernel. >> >> > >> > > BTY, the issue I am trying to debug is when reading bulk IN data from a >> > > USB2.0 device, if the device doesn't have data to transmit and NAKs the >> > > IN packet, after 4 pairs of IN-NAK transactions, xhci stops sending >> > > further IN tokens until the next SOF, which leaves ~90us gape on the >> > > bus. >> > > >> > > But when reading data from a USB2.0 thumb drive, this issue doesn't >> > > happen, even if the device NAKs the IN tokens, xhci still keeps sending >> > > IN tokens, which is way more than 4 pairs of IN-NAK transactions. >> > >> > Thumb drive has Bulk endpoints, what is the other device's transfer type? >> >> It is bulk too. I asked for device descriptors. This is a remote debug >> effort for me, I don't have that device... >> >> > >> > > Any one has a clue on what causes xhci to stop sending IN tokens after >> > > the device NAK'd 4 times? > > By accident, I reproduced the issue if addng a hub in the middle... > any comments about why a hub changes this xhci behavior is appreciated. none off the top of my head. Maybe Mathias can suggest something. >> > tracepoints, please :-) > > I will get tracepoints for cases w/ and w/o a hub. > > Regards, > -Bin. -- balbi signature.asc Description: PGP signature
Re: howto debug xhci driver?
On Mon, Mar 05, 2018 at 01:21:42PM -0600, Bin Liu wrote: > On Mon, Mar 05, 2018 at 10:16:49AM +0200, Felipe Balbi wrote: > > > > Hi, > > > > Bin Liu writes: > > > I am relatively new to xhci and its driver. I am trying to get a xhci > > > driver runtime log to understand how it handles usb transactions, but I > > > don't get much information with dynamic debug (module xhci_hcd) or > > > enabling xhci trace events. Is there any other methods you guys use to > > > debug xhci driver? > > > > tracepoints, the best thing since sliced bread ;-) > > I know, but I didn't get any trace log in bulk IN transfers :( > It turns out - I was on v4.9, which doesn't have much tracepoints. Now I > see you added more since v4.11. I will try to move to the latest kernel. > > > > > > BTY, the issue I am trying to debug is when reading bulk IN data from a > > > USB2.0 device, if the device doesn't have data to transmit and NAKs the > > > IN packet, after 4 pairs of IN-NAK transactions, xhci stops sending > > > further IN tokens until the next SOF, which leaves ~90us gape on the > > > bus. > > > > > > But when reading data from a USB2.0 thumb drive, this issue doesn't > > > happen, even if the device NAKs the IN tokens, xhci still keeps sending > > > IN tokens, which is way more than 4 pairs of IN-NAK transactions. > > > > Thumb drive has Bulk endpoints, what is the other device's transfer type? > > It is bulk too. I asked for device descriptors. This is a remote debug > effort for me, I don't have that device... > > > > > > Any one has a clue on what causes xhci to stop sending IN tokens after > > > the device NAK'd 4 times? By accident, I reproduced the issue if addng a hub in the middle... any comments about why a hub changes this xhci behavior is appreciated. > > tracepoints, please :-) I will get tracepoints for cases w/ and w/o a hub. Regards, -Bin. -- 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: howto debug xhci driver?
On Mon, Mar 05, 2018 at 10:16:49AM +0200, Felipe Balbi wrote: > > Hi, > > Bin Liu writes: > > I am relatively new to xhci and its driver. I am trying to get a xhci > > driver runtime log to understand how it handles usb transactions, but I > > don't get much information with dynamic debug (module xhci_hcd) or > > enabling xhci trace events. Is there any other methods you guys use to > > debug xhci driver? > > tracepoints, the best thing since sliced bread ;-) I know, but I didn't get any trace log in bulk IN transfers :( It turns out - I was on v4.9, which doesn't have much tracepoints. Now I see you added more since v4.11. I will try to move to the latest kernel. > > > BTY, the issue I am trying to debug is when reading bulk IN data from a > > USB2.0 device, if the device doesn't have data to transmit and NAKs the > > IN packet, after 4 pairs of IN-NAK transactions, xhci stops sending > > further IN tokens until the next SOF, which leaves ~90us gape on the > > bus. > > > > But when reading data from a USB2.0 thumb drive, this issue doesn't > > happen, even if the device NAKs the IN tokens, xhci still keeps sending > > IN tokens, which is way more than 4 pairs of IN-NAK transactions. > > Thumb drive has Bulk endpoints, what is the other device's transfer type? It is bulk too. I asked for device descriptors. This is a remote debug effort for me, I don't have that device... > > > Any one has a clue on what causes xhci to stop sending IN tokens after > > the device NAK'd 4 times? > > tracepoints, please :-) I will :) I checked the xhci spec, but didn't find any info on what controls xhci's behavor on IN-NAK... Regards, -Bin. -- 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: howto debug xhci driver?
Hi, Bin Liu writes: > I am relatively new to xhci and its driver. I am trying to get a xhci > driver runtime log to understand how it handles usb transactions, but I > don't get much information with dynamic debug (module xhci_hcd) or > enabling xhci trace events. Is there any other methods you guys use to > debug xhci driver? tracepoints, the best thing since sliced bread ;-) > BTY, the issue I am trying to debug is when reading bulk IN data from a > USB2.0 device, if the device doesn't have data to transmit and NAKs the > IN packet, after 4 pairs of IN-NAK transactions, xhci stops sending > further IN tokens until the next SOF, which leaves ~90us gape on the > bus. > > But when reading data from a USB2.0 thumb drive, this issue doesn't > happen, even if the device NAKs the IN tokens, xhci still keeps sending > IN tokens, which is way more than 4 pairs of IN-NAK transactions. Thumb drive has Bulk endpoints, what is the other device's transfer type? > Any one has a clue on what causes xhci to stop sending IN tokens after > the device NAK'd 4 times? tracepoints, please :-) -- balbi -- 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
howto debug xhci driver?
Hi, I am relatively new to xhci and its driver. I am trying to get a xhci driver runtime log to understand how it handles usb transactions, but I don't get much information with dynamic debug (module xhci_hcd) or enabling xhci trace events. Is there any other methods you guys use to debug xhci driver? BTY, the issue I am trying to debug is when reading bulk IN data from a USB2.0 device, if the device doesn't have data to transmit and NAKs the IN packet, after 4 pairs of IN-NAK transactions, xhci stops sending further IN tokens until the next SOF, which leaves ~90us gape on the bus. But when reading data from a USB2.0 thumb drive, this issue doesn't happen, even if the device NAKs the IN tokens, xhci still keeps sending IN tokens, which is way more than 4 pairs of IN-NAK transactions. Any one has a clue on what causes xhci to stop sending IN tokens after the device NAK'd 4 times? Thanks, -Bin. -- 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