On Mon, Oct 03, 2016 at 07:08:43PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> ville.syrjala@xxxxxxxxxxxxxxx writes:
> > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> >
> > This reverts commit 55a0237f8f47957163125e20ee9260538c5c341c.
> >
> > commit 55a0237f8f47 ("usb: dwc3: gadget: use allocated/queued reqs for
> > LST bit") causes my BYT FFRD8 with g_ether to behave poorly. ssh/scp
> > is very sluggish and can even stall entirely. Revert cures it.
> >
> > Cc: Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx>
> > Cc: stable@xxxxxxxxxxxxxxx
> > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
>
> Reverting that commit is not the best idea. Let's start with the usual:
>
> - Kernel version
> - dmesg on both sides (host and device)
> - dwc3 tracepoints:
>
> # mkdir -p /t
> # mount -t tracefs none /t
> # echo 8192 > /t/buffer_size_kb
> # echo 1 > /t/events/dwc3/enable
> # echo 0 > /t/events/dwc3/dwc3_readl/enable
> # echo 0 > /t/events/dwc3/dwc3_writel/enable
>
> This should be enough to tell me what's really going on.
I've attached the (compressed due to size) dmesgs/traces from the device.
For my test I just did 'for i in `seq 1 5` ; dmesg ; done' in an ssh
session, and I did get the lag in the bad run, so presumably the trace
should have caught it. Both were on 4.8 (+ the revert for the good run).
Host side dmesg just showes me:
usb 3-3.4: new high-speed USB device number 25 using xhci_hcd
cdc_ether 3-3.4:1.0 usb0: register 'cdc_ether' at usb-0000:00:14.0-3.4, CDC Ethernet Device, ...
when I boot the device. Nothing extra appears when things lag around.
I'm running 4.5.something on the host.
--
Ville Syrjälä
Intel OTC
Attachment:
bad.dmesg.gz
Description: Binary data
Attachment:
bad.trace.gz
Description: Binary data
Attachment:
revert.dmesg.gz
Description: Binary data
Attachment:
revert.trace.gz
Description: Binary data