Sander, Please try this patch3. Before you apply this patch, make sure to apply "xHCI: update ring dequeue pointer when process missed tds" patch first. I attach it too. Thanks & Best regards, Andiry > -----Original Message----- > From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] > Sent: Wednesday, August 11, 2010 1:41 AM > To: Sander Eikelenboom > Cc: Xu, Andiry; linux-usb@xxxxxxxxxxxxxxx > Subject: Re: xhci_hcd ERROR no room on ep ring, xhci_hcd WARN Event TRB > for slot 1 ep 4 with no TDs queued? > > On Sun, Aug 08, 2010 at 12:44:19PM +0200, Sander Eikelenboom wrote: > > Hello Andiry, > > > > Attached is the syslog output with the DMA error on a kernel with patch3 > applied. > > What's the base kernel you're patching? Is it from my master branch, or > are you taking a stock kernel and patching it with Andiry's isoc > patches? Which driver is loaded for your device? > > > BTW, i haven't seen a pull request for xhci and the isoc patches for the > 2.6.36 merge window yet ? > > Greg has the patches in his queue (he has a quilt patchset, so he > doesn't ask for pull requests). > > So the interesting part of your isoc endpoint ring is this: > @c7df5660 c7a2a5d0 00000000 00040b4c 80001424 > @c7df5670 c7a2b11c 00000000 00040b4c 80001424 > @c7df5680 c7a2bc68 00000000 00040b4c 80001424 > @c7df5690 c7a2c7b4 00000000 00040b4c 80001424 > @c7df56a0 c7f103d4 00000000 00040b4c 80001425 > @c7df56b0 c7f10f20 00000000 00040b4c 80001425 > ... > ERROR Transfer event TRB DMA ptr not part of current TD > ep 4, skip is not set > isoc ep > ep_ring->deq_seg = ffff88001f7362a0 > ep_ring->dequeue = ffff88001f798120 > td->last_trb = ffff88001f798120 > event_dma = 0xc7df5680, @ffff88001e6eb4b0 > > The printed dequeue pointer is a virtual pointer, so it's not very > helpful in correlating where the endpoint dequeue pointer is. > > Andiry, maybe you can rev the third patch to use xhci_trb_virt_to_dma()? > That way you can see why the xHCI driver claims the event isn't part of > the current TD, when the transfer events on the ring look fairly sane (a > successful event for c7df5660, c7df5670, and c7df5680). > > Your log shows some other interesting events on the event ring: > > Event Ring: > @c7df3490 c7df5660 00000000 01000000 01058001 > @c7df34a0 c7df5670 00000000 01000000 01058001 > @c7df34b0 c7df5680 00000000 01000000 01058001 > @c7df34c0 00000000 00000000 15000000 00009401 > @c7df34d0 c7df5690 00000000 01000000 01058001 > @c7df34e0 00000000 00000000 15000000 00009401 > @c7df34f0 00000000 00000000 0f000000 01058001 > @c7df3500 c7df52a0 00000000 01000000 01058000 > > This TRB in particular: > @c7df34c0 00000000 00000000 15000000 00009401 > > The completion code is 0x15, or 21, which is an Event Ring Full Error. > There's a second one on the ring, which is very odd. If the ring was > full, how could the host manage to fit two events on the event ring? > > The xHCI driver currently doesn't handle expanding the event ring, but I > had thought that it wouldn't get 62 events in one interrupt. I think > there's some deeper issue here. Maybe my commit to move the hardware > event ring dequeue pointer writes after all events have been handled is > to blame? > > Sander, do you have a commit with this short description: > "xhci: Minimize HW event ring dequeue pointer writes."? > > The last TRB on the event ring is an isochronous Ring Overrun Event: > @c7df34f0 00000000 00000000 0f000000 01058001 > > That should be harmless. It just means the driver didn't queue an > isochronous transfer before the host went to look at the ring. The > periodic schedule will be started on the next transfer when the doorbell > is rung. Perhaps since you're using Xen, the computer is rather slow? > > Sarah Sharp
Attachment:
isoc_length3.patch
Description: isoc_length3.patch
Attachment:
0001-xHCI-update-ring-dequeue-pointer-when-process-missed.patch
Description: 0001-xHCI-update-ring-dequeue-pointer-when-process-missed.patch
