On Fri, Apr 19, 2013 at 02:26:48PM +0200, Karsten Malcher wrote: > Hi Johan, > Am 19.04.2013 11:04, schrieb Johan Hovold: > >> This was a log with lost data. > >> The logs seems to make politics. ;-) > > Then the problem is most likely not in the driver as the characters are > > being read back in the log you provided. > > Stop - it's really possible that i send not enough bytes. > Sometimes up to 6 Bytes will come back. > > This time i send this string (3.2.0): > "1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890\n" > I get back the first 3 Bytes of it. > Log is attached.
Was it really the same log? In the log below there is an error reported but it looks like no data at all is returned: > [ 1443.120415] > /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/generic.c: > usb_serial_generic_write - port 0 > [ 1443.120430] pl2303 ttyUSB0: usb_serial_generic_write_start - length = 101, > data = 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 > 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 > 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 > 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 0a > [ 1443.122568] > /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/generic.c: > usb_serial_generic_read_bulk_callback - nonzero read bulk status received: > -84 Either way, the error is EILSEQ (-84) which usually indicates hardware problems. [...] > There are 2 beasty questions left: > 1. Why it works with PL2303H ? Different device, different hardware. > 2. Why i receive sometimes the first bytes? Your particular device could be flakey and sometimes you're able to read a few bytes. > > Now that you have compiled your own kernel, you could run a git bisect > > to learn if anything else has changed in the kernel (possibly > > interacting with your test setup) which can explain why things > > stopped working. > > I learned much in kernel testing the last time ... :-) > Maybe there is a HowTo for the bisect testing? I don't have any good pointers at hand except for the git documentation of git-bisect. But perhaps you don't need to do a bisect. If the hardware is broken then knowing which performance increase in the kernel pushed it over the edge isn't really gonna be of much use as the driver is still working with other HX-devices (I have one here). If you still want to pursue this, you should try to reproduce the error on a v3.8 kernel (look in the logs for errors from usb_serial_generic_read_bulk_callback). Then you could try to reduce the bulk-in and out buffer sizes in the driver (simply comment out those fields in the pl2303_device struct) and perhaps also to reduce the number of read and write urbs (I can tell you how later). Johan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
