PROBLEM: USB isochronous urb leak on EHCI driver
Alan Stern
stern at rowland.harvard.edu
Wed Feb 11 03:01:32 AEDT 2015
On Tue, 10 Feb 2015, Michael Tessier wrote:
> > > Okay; I did my homeworks. We've loaded kernel V3.16 (Oct 14th, 2015)
> > > on an i.MX51 plattform and the problem is still there. Unless an
> > > important change occured in V3.19, it appears that the latest kernel
> > > is not the solution for us. So we're still not able to use 4 codecs on
> > > our i.MX plattform.
> > >
> > > So just to make things clearer:
> > > - We have customers waiting for a solution with that hardware (this
> > > hardware is already delivred AND used);
> > > - We have important comittments and severe penalties ($$$) if we're
> > > not able to deliver on time (due for March 15th);
> > > - We've already looked at a hardware solution, which corresponds to
> > > replace current units ($$$$$), so that is not really an option for us;
> > >
> > > So as a last resort, I'm wondering, where is the USB expert who could
> > > help us solving our problem? Any suggestions?
> >
> > That would be me.
>
> Great. What do you need to make it a priority?
Let's put it this way: Fixing bugs in the ehci-hcd driver already is a
priority for me. But it takes second place to other priorities, such
as my day job.
(And incidentally, finding and fixing bugs in kernels as old as 2.6.31
is _not_ a priority, since so many have already been found and fixed.
That is one important reason for my suggestion that you do the
debugging with the most recent kernel version you can.)
> > > If we are to get into debugging the USB driver, we would do it with
> > > the current kernel used (V2.6.31). What are the better tools to get
> > > into that? I guess a USB analyzer (hardware) would be the smart thing?
> > > Any brand name to suggest?
> >
> > It really would be better to start by debugging the most recent kernel possible. Once the problem has been solved there, it should be fairly straightforward to port it back.
>
> How much time do you think you'd spend solving that kind of issue?
> Few days? Few weeks, or few months?
No idea. In the past, such things have taken a few days to a few
weeks, depending on lots of factors -- when they are solvable at all.
> Could you commit on a certain
> number of hours? (We are trying to evaluate a possible date where we
> could start delivering products)
No, I can't commit to anything specific.
> When you say "straightforward", again do you have an idea of the
> amount of time to do such work?
Again, it all depends. For example, it might turn out that the
hardware you are using contains a bug of a sort I have seen in the
past. In that case, programming a workaround wouldn't take more than a
few hours, once I knew what was going on.
Alan Stern
More information about the Linuxppc-dev
mailing list