On Tue, Mar 20, 2018 at 09:14:12AM +0200, Felipe Balbi wrote: > > Hi, > > Bin Liu <b-liu@xxxxxx> 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 <b-liu@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
