Re: usb: dwc2: usb data transmitted to incorrect usb endpoint

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

 



Hi Maynard,

On 1/24/2019 12:13 AM, Maynard Cabiente wrote:
> Hi Minas,
> 
> On Wednesday, January 23, 2019 3:58 AM Minas Harutyunyan
> <minas.harutyunyan@xxxxxxxxxxxx> wrote:
>> But before it, could you please add some debug print in
>> dwc2_hsotg_suspend() function. I suspect that host side autosuspend mass
>> storage device(s) this is why dwc2 driver complete request with ERROR:
>> -108. Based on debug log:
>>
>> [  368.964378] dwc2 ffb40000.usb: dwc2_hsotg_ep_queue: [req ce60a380]
>> ep1 out: 512@ce188000, noi=0, zero=0, snok=0 (new CBW for ep1)
>> [  368.967886] configfs-gadget gadget: End Point Request ERROR: -108
>> <-- ERROR DUE TO USB DATA TRANSMITTED TO INCORRECT USB EP
>>
>> I see >3ms inactivity which can be reason to suspend bus.
>> If my assumption is correct then you can disable autosuspend feature of
>> connected devices.
>>
> 
> There is actually a debug log in dwc2_hsotg_suspend function():
> 
> if (hsotg->driver) {
>          int ep;
>          dev_info(hsotg->dev, "suspending usb gadget %s\n",
>                        hsotg->driver->driver.name);
> .......
> 
> However, I searched in my logs on all the runs I did that reproduced
> the issue and that message is not present on all of them. So, suspend
> is not happening in this case.
> 
>> I don't know about email attachments size limits. Actually, you can
>> truncate (save as required parts) whole USB trace.
>>
> 
> Posting below the USB trace (exported text file) where the problem lies.
> 
> Regards,
> Maynard
> 
Besides, mentioned by you timestamp <23.918 564 900>, where BULK IN data 
messed between EP1IN and EP2IN, I found in USB trace one more invalid 
traffic packets sequence. See in trace at timestamp <24.169 347 217>: on 
same EP1 to CBW (Mode Sense) command 31 bytes, device reply as IN data 
128 bytes and first 31 bytes are SAME from CBW. That mean buffer pointer 
set incorrectly EP1IN pointer set to EP1OUT pointer. In case of DDMA 
buffer pointer is descriptor pointer.

Difference between this 2 cases:
1. When EP different (your case) SCSI Tag's also different this is why 
class driver issue reset.
2. When EP same then (my case) SCSI Tag's are same, just wrong data from 
class driver point of view, and later class driver again send Mode Sense 
command which completed OK and no reset initiated.

I not found yet where from come this bug.

Meanwhile, could you please:
1. Test same scenario in BDMA mode
2. Provide me full debug messages log for DDMA around when the issue seen.
It's not core bug it's dwc2 bug.

Thanks,
Minas




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

  Powered by Linux