RE: unable to handle EVENT RING FULL error in xhci

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

 



Hi Mathias,

> -----Original Message-----
> From: Mathias Nyman [mailto:mathias.nyman@xxxxxxxxxxxxxxx]
> Sent: Friday, January 20, 2017 10:38 PM
> To: gregkh@xxxxxxxxxxxxxxxxxxx; Anurag Kumar Vulisha
> <anuragku@xxxxxxxxxx>
> Cc: linux-usb@xxxxxxxxxxxxxxx; mathias.nyman@xxxxxxxxx; Punnaiah
> Choudary Kalluri <punnaia@xxxxxxxxxx>
> Subject: Re: unable to handle EVENT RING FULL error in xhci
> 
> 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.
>
 Driver is asking for 48K and the Synopsys dwc3 controller is supporting only
Burst length of 16. So, on lecroy trace we see > 3 burst transactions for 48K
Chunk.

Randomly we are observing stale data from (based on the uvc header info)
the camera and during that time we see that the ACK from the host is delayed
by >4 milli seconds for one of the data packet with in a burst.

We are unable to figure out why this much delay. 
Any pointers or help to probe further ?  
 
>   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.

Correct but the URB processing is happening in interrupt context and since the uvc
Layer is copying the 48k chunk of data to the upper layer buffer using memcpy.
So, we changed the URB processing context to bottom half and now we didn’t
Observe any EVENT_RING_FULL message but our original issue of receiving the 
Corrupted frames from the camera still there.  


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

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

Ok

Thanks.

Regards,
Punnaiah

> -Mathias

��.n��������+%������w��{.n�����{���)��jg��������ݢj����G�������j:+v���w�m������w�������h�����٥




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

  Powered by Linux