Zitat von Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
On Tue, 5 Feb 2019 guido@xxxxxxxxxxxxxxxxxx wrote:
Zitat von Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> On Mon, 4 Feb 2019, Guido Kiener wrote:
>
>> From: Guido Kiener <guido.kiener@xxxxxxxxxxxxxxxxx>
>>
>> The OUT endpoint normally blocks (NAK) subsequent packets when a
>> short packet is received and returns an incomplete queue entry to
>> the gadget driver. Thereby the gadget driver can detect
>> a short packet when reading queue entries with a length that is
>> not equal to a multiple of packet size.
>>
>> The start_queue() function enables receiving OUT packets regardless
>> of the content of the OUT FIFO. This results in a problem:
>> When receiving is enabled more OUT packets are appended to the last
>> short packet and the gadget driver cannot determine the end of a
>> short packet anymore. Furthermore the remaining data in the OUT FIFO
>> is not delivered to the gadget driver immediately and can produce
>> timeout errors.
>
> How can that happen? When the short packet is received, the endpoint
> immediately starts sending NAKs, so no more data can enter the FIFO.
> Furthermore, the incomplete transfer is returned to the gadget driver,
> which removes the short packet from the FIFO. So the FIFO has to be
> empty when start_queue() is called.
I don't remember the exact scenario. It happens something like this:
When you have only one request (e.g. 4kB) left in your endpoint OUT
queue and a host sends 4kB + some extra bytes, then your request (4kB)
is delivered to the gadget driver while the extra bytes (short packet)
are still in the OUT FIFO.
I try to reconstruct the situation (without fix) how the driver can call
(re)start_dma. I do not see a reasonable path in the moment.
Okay, I see. If there's no outstanding request when the short packet
arrives, the data will remain in the FIFO.
But won't this situation be detected in start_dma(), which is the only
place where start_queue() is called? start_dma() has code to test
specifically for a previous short OUT packet. Should the fix go there
instead?
You are right. Unfortunately I did not save a callstack. I guess it was
more a restart_dma(). We do a lot of unusual things like stalling endpoints,
clear_halt, dequeue requests and so on.
The biggest problem is to stop/abort the DMA (I have some more comlexer
patches in the queue). I just remember that it took me a long time to find
this bug and I try to reproduce it this week.
Guido
