Bug#704242: Driver for PL-2303 HX not working
On Sat, Apr 20, 2013 at 09:50:52AM +0200, Karsten Malcher wrote:
> Am 19.04.2013 16:39, schrieb Johan Hovold:
> >
> >>> 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:
>
> No - this are of course different tests and different logs.
> Sorry - it's possible that there where no bytes read back in this particular test.
> I added exact output to my script now.
>
> Here are two additional tests with 50 bytes (3.2.0).
> In sendtest50get2.log i definitely read 2 Bytes back.
Yes, in the logs 2 and 4 bytes respectively is received before the same
hardware related error EILSEQ (-84) is received.
> >> [ 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.
>
> Maybe this time not plugged in perfectly.
> This cheap connectors are sometimes not reliable.
> It's the same connecting an external harddisk - sometimes you have a bad connection.
>
> >> There are 2 beasty questions left:
> >> 1. Why it works with PL2303H ?
> > Different device, different hardware.
>
> But it's the same driver or not?
Yes, same driver.
> >> 2. Why i receive sometimes the first bytes?
> > Your particular device could be flakey and sometimes you're able to
> > read a few bytes.
The new logs seem to support this.
> Sorry - i don't think so.
> 1. It works perfect with kernel 2.6.32
> 2. It works perfect using windows with the driver from Profilic
> 3. I have 2 devices of this type and the behaviour is exact the same
All three could be explained by flakey hardware. The 2.6.32 driver and
possibly the Windows driver could be inefficient enough not to trigger
the problem as reliably as the current Linux driver do.
You did say it was a pirate chip, right? In the debian bug tracker
someone also mentioned having an HX device with the exact same
descriptors? If so we would never even be able to identify the broken
devices if a work-around could be could be found.
A quick test you could do (before reducing buffer sizes and urb counts)
is to see what happens if you pace the writes to the device. Say if your
test program writes one byte per second? Are more bytes received then?
Johan
Reply to: