Tuesday, August 10, 2010, 7:41:14 PM, you wrote: > 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? It was 2.6.35-rc6, with 4 or 5 additional patches from you, and Andiry's isoc patches on top of that. I will redo with 2.6.35 final and Andiry isoc patches and kmemleak + debugfs turned on. >> 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). Ok good to know :-) > 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."? Nope that one doesn't seem to be in. > 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? Well it has gone from a AMD dual core to a six core, and together with that from usb2 controller to a usb3 controller (usb3 pci-express controllers are cheaper than usb2 over here). And with the old setup i used 2 usb2 controllers with one videograbber each on running on Xen, grabbing 24/7 for weeks without a problem. So it should be able to work one would say :-) In the first setup i had an extra USB3 controller, that i used with some ancient Isoc patches Andiry cooked up from 2.6.33, and that actually worked well (with another grabber than i'm using now). So it shouldn't be the boxes performance. Though Xen could be related, it at least isn't performance wise. Sarah Sharp -- Best regards, Sander mailto:linux@xxxxxxxxxxxxxx -- 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
