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.)?
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...
thanks,
greg k-h
--
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
