Re: unable to handle EVENT RING FULL error in xhci

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20.01.2017 10:41, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
On Fri, Jan 20, 2017 at 07:59:48AM +0000, Anurag Kumar Vulisha wrote:
Hi,

Hi!

Minor nit, vger.kernel.org rejects html emails, so this didn't make it
through to that list.  Now it should with my response :)

I have a usecase where I want to stream a stereo video from the ZED Stereo
Camera  (www.stereolabs.com) by connecting it  to our ZynqMP SOC based platform
using the USB 3.0 interface. This camera keeps on streaming 48k chunks of BULK
data to the HOST.

Any idea what size chunks the driver is asking for? if URB asks for > 48k then
we would have a lot of short packet events on the event ring.

 Initially the data is received correctly, but after some time
I noticed frame corruption on the BULK packets received by HOST controller. On
debugging I found that HOST event ring is full and it issues “EVENT RING FULL
ERROR” and this error seems to be not handled in XHCI. I am using linux 4.6
kernel for testing . Please help me in by giving any suggestions on how to
handle this issue? Currently I increased the TRB_PER_SEGMENT from 256 to 512
but the issue seems to delayed and gets reproduced after some more time.

We are currently not handling EVEN_RING_FULL_ERRORS at all, that should be fixed.

256 is a nice number because with 16byte TRBs we end up with ring segments of size
4096 Bytes.

xhci driver is only using one event ring, the primary one, for all transfer,
command completion and port status events.
If I remember correctly that event ring only has one segment.


To increase the TRB_PER_SEGMENT from 256 to 512 I made the below changes

         xhci->segment_pool = dma_pool_create("xHCI ring segments", dev,
TRB_SEGMENT_SIZE, TRB_SEGMENT_SIZE, xhci->page_size * 4);

Is this the correct way ? or I am doing wrong.

Probably best to check what the event ring is full of first, maybe dumping it.

It could be just about the ring size, or then it could be filled with unnecessary
events (short transfers), or then we are handling some other slow event that
with interrupts disabled.
Or then we just don't generate interrupts, or they are disabled, preventing us from
handling events on the ring.

A 2k USB 3 stereo camera seems like a devie that generates a lot of traffic and
events.


It would be very helpful if you can help me in solving this issue

4.6 is very old and obsolete and behind in a lot of xhci fixes.  Can you
test 4.9.4 or even better yet, Linus's 4.10-rc4 tree to see if the issue
is still there?


A more recent kernel would be preferred, dumping the event ring could be done
using something like this:

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 5e51109..3e6a816 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2575,6 +2575,9 @@ static int xhci_handle_event(struct xhci_hcd *xhci)
                if (ret >= 0)
                        update_ptrs = 0;
                break;
+       case TRB_TYPE(TRB_HC_EVENT):
+               xhci_debug_segment(xhci, xhci->event_ring->deq_seg);
+               break;
        case TRB_TYPE(TRB_DEV_NOTE):
                handle_device_notification(xhci, event);
                break;

And enable xhci debugging, but only for xhci_debug_segment() function

-Mathias

--
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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux