On Fri, Jul 27, 2012 at 03:00:53AM +0000, Xu, Andiry wrote: > > -----Original Message----- > > From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb- > > owner@xxxxxxxxxxxxxxx] On Behalf Of Sarah Sharp > > Sent: Friday, July 27, 2012 4:22 AM > > To: Matthew Hall > > Cc: linux-usb@xxxxxxxxxxxxxxx; gem@xxxxxxxxxx > > Subject: Re: the dreaded "needs XHCI_TRUST_TX_LENGTH quirk" returns > > > > On Thu, Jul 26, 2012 at 07:16:38AM -0700, Sarah Sharp wrote: > > > On Wed, Jul 25, 2012 at 10:24:26PM -0700, Matthew Hall wrote: > > > > On Wed, Jul 25, 2012 at 10:46:37AM -0700, Sarah Sharp wrote: > > > > I think I'm in the same state as Gary only different. ;) I am > > > > getting weird behavior with the quirk patch. The device popped up > > > > for about half a minute, then went haywire and disappeared after the > > > > exfat FUSE FS tried to mount it and begin reading the volume > > successfully for a short moment. > > > > > > I think now that your host is working, you're running into a separate > > > bug that several other people have discovered. Your mass storage > > > device stalls a lot of SCSI commands (which is fine), and that > > > eventually hits a bug when the stall happens just before the end of a > > > transfer ring segment boundary. > > > > > > The bug causes this message to appear: > > > ERROR Transfer event TRB DMA ptr not part of current TD > > > > Ok, I think I have the root cause of this message, and it's a nasty little > > bug. Can you apply the attached patch (instead of the previous debug patch) > > and test? I think your disk will work once it's applied, but please double > > check that you don't see any more of that ERROR message. > > > > I have one question about the patch - why does the issue not occur without > ring expansion patches? If there is only one ring segment and the dequeue pointer > is pointed to the Link TRB, the inc_deq() will also move dequeue pointer out of > the segment, and it will not even wrap back, which is worse. But it will wrap back into the right place in the segment eventually, thanks to code like this in finish_td(): } else { /* Update ring dequeue pointer */ while (ep_ring->dequeue != td->last_trb) inc_deq(xhci, ep_ring); inc_deq(xhci, ep_ring); } inc_deq will be called until the dequeue pointer is equal to the last TRB in the TD, even if that means wrapping through memory. :( I'm really hoping I'm wrong about the impact of this bug, but I can't see how else the code could have succeeded when the dequeue was moved to the link TRB. Sarah Sharp -- 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
