Re: xhci and other woes

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

 



On Mon, Feb 03, 2014 at 04:45:14PM +0000, David Laight wrote:
> From: David Laight
> > From: David Laight
> > > From: renevant@xxxxxxxxxxxx.
> > > But there are also further issues I'm about to look at.
> > > Short 'ping' requests work, but a 'netperf' tcp rr test with 8k blocks
> > > (which probably generates sg transmits) fails generating some
> > > 'TRB DMA ptr not part of current TD' errors.
> > > I think I've seem that when a 'TRB error' is reported (when I was using the
> > > wrong type of NOP). I'm about to investigate what is being errored here.
> > 
> > In this case they happen when receive buffers cross 64k boundaries
> > and so are split into two TRBS.
> > The controller is generating one event for the 'short transfer' and
> > a second for the last TRB - by which time the TD and URB have already
> > been cleared up.
> 
> From the end of section 4.10.1.1 (Short transfers)
> - If the Short Packet occurred while processing a Transfer TRB with only an
>   ISP flag set, then two events shall be generated for the transfer;
>   one for the Transfer TRB that the short packet occurred on, and a second
>   for the last TRB with the IOC flag set.
> - Software shall not interpret an Short Packet Event as indicating that the
>   TD that it is associated with is “complete”, unless the TRB Pointer field
>   of the Transfer Event references the last TRB of the TD.

And there's code in the xHCI driver to ignore the second successful
event.  See ep->last_td_was_short.  Yes, this is a slight race
condition, and we should wait for the successful event.  However, we
have not seen any issues with this race condition.

> Which means that the controller is obeying the rules, and the software is wrong.

I think your mindset isn't helpful here.  Software is full of bugs.
Some bugs we know, some bugs we'll never find.  Software will never be
perfect.  The questions to ask when discovering a bug are:

1. What is the impact of this bug?  Is it user-visible?
2. How many customers are impacted by this bug?
3. What is the software complexity of fixing this bug?
4. What are the chances of the fix causing other issues?

In this case, the bug has been worked around (not perfectly), but we've
had no customer reports that this is an issue.  There is no user-visible
impact as far as we know.  So fixing this race condition is a really low
priority for me, and the fix would have to very minimally touch the
driver.

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