On Thu, Aug 13, 2015 at 11:55:07AM -0700, Greg KH wrote:
> On Thu, Aug 13, 2015 at 01:44:24PM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Thu, Aug 13, 2015 at 01:37:19PM -0500, Felipe Balbi wrote:
> > > Hi,
> > >
> > > I have reproduced this write failure very reliably with two different
> > > hosts (my xHCI Desktop and AM335x with MUSB).
> > >
> > > It's very simple to reproduce with the ruby script below:
> > >
> > > #!/usr/bin/env ruby
> > >
> > > 1000000.times do |amt|
> > > File.open("/dev/ttyUSB0", 'w') do |write|
> > > str = "a" * (amt + 1)
> > > puts "writing #{str.length} bytes to #{write.path}"
> > > write.puts str
> > > end
> > > end
> > >
> > >
> > > Basically, CP2108 stops sending data and starts NAKing any IN tokens
> > > from the host. Attached you can find a fresh sniffer capture of the
> > > problem reproduced with AM335x running today's linux-next.
> > >
> > > To read the sniffer capture, you'll need DataCenter SW which can be
> > > downloaded from [1] (there are binaries for Windows, Linux and Mac.
> > > You'll need gstreamer0.10 to run).
> > >
> > > There are ways to make it behave. If I add a reading thread reading from
> > > ttyUSB1 with a null modem cable routed from ttyUSB0 to ttyUSB1, then it
> > > works. It also works by adding a sleep or enough debugging messages.
> > >
> > > Let me know if you need any extra information to reproduce this problem.
> > >
> > > Attached you can also find a screenshot with a snipet of the sniffer
> > > capture showing the timed out control transfer and a little context
> > > around it.
> > >
> > > [1] http://www.totalphase.com/products/data-center/
> >
> > resending without attachments, you guys already got it anyway :-p
>
> Do other usb-serial devices succeed with this test (pl2303, ftdi, etc.)?
FTDI seems to work fine (ran all the way to 5000+ bytes before I stopped
it), no pl2303 here though :-s
> Given that there is no specific write-path code for this driver, it's
> using the usb-serial core, so odds are, the chip itself is just not
> liking being sent this much data all at once, so it dies. These really
> are horrible little chips, it's amazing they even work at all at
> times...
that's what I figured, still good to check anyway. It doesn't seem to be
reproducible with AM437x (which has a USB2-only XHCI implementation -
yeah, don't ask), but maybe it's more related to extra latency due to
XHCI running on a single core A9 in comparison to my 8-core desktop.
Oh well, just blame the chip, I guess :-p
--
balbi
Attachment:
signature.asc
Description: Digital signature
