Bug#704242: Driver for PL-2303 HX not working
On Tue, Jan 14, 2014 at 12:01:30AM +0100, Karsten Malcher wrote: Hello together, i will close this bug at Debian now. After the last update this error seems to disappear in Debian stable. http://ftp.debian.org/debian/dists/wheezy/ChangeLog USB: pl2303: fix device initialisation at open That's good to hear. The source for this patch can be found here: http://www.spinics.net/lists/stable/msg30311.html This is not directly related to commit you refer to above (it fixes a different problem). It's possible that this will not fix the bug under all circumstances depending on the application. Summary: == I did need some time to realize that this bug will occur only with PL2303HX chips that are China clones. In fact this type of chips run out of production at Profilic. http://www.prolific.com.tw/US/ShowProduct.aspx?pcid=41showlevel=0017-0037-0041 Only the PL2303HXD can be buyed as original, so any new PL2303HX is a China clone. I have been contacted by Frank Schäfer and so we tested some of his driver improvements in combination with newer kernels. Up to now this could not be backported to kernel 3.2.x, but i could test a kernel 3.12.6 on Debian wheezy and the PL2303HX is running fine. There are really much products with this clone chips out there, so some further improvements of the driver would be really helpful. I will make further tests together with Frank and hope that this improvements will find a place into the next kernel versions starting with Debian jessie and 3.12.6 The pl2303 has been cleaned up quite a bit lately (will show up in v3.14), so it should be even easier to add support for further device types with all their quirks. Patches are most welcome. Thanks, Johan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140115130556.GF11681@localhost
Bug#704242: Fwd: Re: Bug#704242: Driver for PL-2303 HX not working
On Mon, Jun 24, 2013 at 10:41:07AM +0200, Karsten Malcher wrote: Hello Greg, have you buyed one of this jinxed PL-2303 HX adapters? Yesterday i got this interesting mail from Aric, who has analyzed a similar problem with this chip. Why do you think that this is related to the problems you were experiencing back in April? Your logs contained indications of hardware errors: usb_serial_generic_read_bulk_callback - nonzero read bulk status received: -84 which are not present in Aric's logs. His stackoverflow post http://stackoverflow.com/questions/16832281/strange-bit-shifting-when-pl2303-connected-to-cp210x also describes a different problem (odd bitshifts and inversions rather than dropped data due to detected hw errors). Specifically, no data is lost in Aric's case, rather it appears to be received garbled. I think something went wrong in the usb serial handling, but not in the driver itself. But the error is really complicate to figure out in the depth of the software. The really annoying thing is that it worked with kernel 2.6.32. Just to be clear, that's your setup. AFAICT Aric never got his setup to work with any kernel (but for a brief period with the same 3.0 kernel). As we discussed in April, there has been a lot of changes (including performance improvements) made to the pl2303 driver since 2.6.32 which could possibly explain why you did not trigger your (suspected) hw error on really old kernels. Thanks, Johan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130625165442.GA18968@localhost
Bug#704242: Fwd: Re: Bug#704242: Driver for PL-2303 HX not working
On Tue, Jun 25, 2013 at 07:12:28PM +0200, Karsten Malcher wrote: Am 25.06.2013 18:54, schrieb Johan Hovold: On Mon, Jun 24, 2013 at 10:41:07AM +0200, Karsten Malcher wrote: Hello Greg, have you buyed one of this jinxed PL-2303 HX adapters? Yesterday i got this interesting mail from Aric, who has analyzed a similar problem with this chip. Why do you think that this is related to the problems you were experiencing back in April? Maybe Aric can explain it better? I only see several problems to use a PL-2303 HX with newer kernels. Just to be clear, that's your setup. AFAICT Aric never got his setup to work with any kernel (but for a brief period with the same 3.0 kernel). The only solution i see is to give up any PL-2303 HX device like Aric. But the problems for other users will remain ... Only if the hardware is actually broken, of course. I'm just saying that it looks like two different (hw related) problems here. As we discussed in April, there has been a lot of changes (including performance improvements) made to the pl2303 driver since 2.6.32 which could possibly explain why you did not trigger your (suspected) hw error on really old kernels. I remember a similar discussion on not reliable usb connectors with external hdd's. This connectors are often produced cheap and the connection is not reliable each time after plugin. When you argue that you must forget each device or hardware in case of an error, you can forgot much usb devices using with Linux. (In fact windows just ignores the errors.) My forecast is that the number of sporadic errors will increase, specially with usb 3. Sure, if it is something that can be worked around in software without too much overhead for non-broken devices (I have only a working HX here), then we can try it. Perhaps the device you were gonna send to Greg can be used to implement such a work-around (or at least be used to determine the cause of the problem). Johan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130625172910.GA28700@localhost
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 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130420091825.GA21315@localhost
Bug#704242: Driver for PL-2303 HX not working
On Fri, Apr 19, 2013 at 09:25:19AM +0200, Karsten Malcher wrote: Am 18.04.2013 11:35, schrieb Johan Hovold: I have used a little perl program that opens the port and send Test to the looped back device. The length of the log looks good. Great. Now I can see what's going on. The only problem (?) is that everything seems to be working. The write succeeds and the four bytes are read back as they should by the driver. But where the data has gone? With cutecom i can see that some of the first bytes are looped back. It must be possible to read any binary (streamed) data. Yes, but not in canonical mode as then the input is buffered by the kernel tty-layer until certain characters are encountered. The first thing that comes to mind that could prevent you from reading the received data would be if the tty device is configured for canonical input processing. Have you made sure this is not the case? Can you read the data back if you add a newline to your test string (e.g. test\n)? Hmmn - i don't know which method is used by programs like cutecom or putty? Unless it's configurable it should be non-canonical mode. But i know everything works fine before. In this programs every data is terminated with newline, but it does not work. You mean that you updated your test program so that it writes test\n but it still does not work? I use this script with a ch341 adapter and it works. Hmmm. Did you remember to initialise the device (e.g. set the termios flags)? Here you can see what's initialized in Perl: use Device::SerialPort 0.12; $port-baudrate(9600) || die failed setting baudrate; $port-parity(none)|| die failed setting parity; $port-databits(8) || die failed setting databits; $port-handshake(none) || die failed setting handshake; $port-write_settings|| die could not write settings; $port-lookclear || die could not empty buffer; $port-read_char_time(0);# don't wait for each character $port-read_const_time(1000);# 1 second per unfulfilled read call my $STALL_DEFAULT = 1;# how many seconds to wait for new input I don't use perl so can't help you there. Search for perl and icanon or something. You can use stty to determine if canonical-mode is enabled; the output of 'stty -aF /dev/ttyUSB0' contains icanon if enabled and -icanon otherwise. By default it is enabled. You should also make sure that VMIN and VTIME are initialised in non-canonical mode. Specifically, if VMIN is greater than the number of characters written by your test program over the loopback and VTIME is 0, read will block also in non-canonical mode. Johan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130419084928.GA32104@localhost
Bug#704242: Driver for PL-2303 HX not working
On Fri, Apr 19, 2013 at 10:36:57AM +0200, Karsten Malcher wrote: Am 18.04.2013 12:56, schrieb Johan Hovold: Can you generate a log where bytes are actually lost? Nothing seemed to get lost in the previous log you posted. 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. 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 would suggest that you convince yourself that your minimal test setup is correct first, though. Perhaps using the same minimal program (init, write, read) on a working pl2303 device if you have one. How can i enable the debugging in kernel 3.8.5? Make sure debugfs is mounted: mount -t debugfs none /sys/kernel/debug and then enable debugging: echo module usbserial +p/sys/kernel/debug/dynamic_debug/control echo module pl2303 +p/sys/kernel/debug/dynamic_debug/control Johan Sorry - this does not work for me? root@PC# mount -t debugfs none /sys/kernel/debug root@PC# mount sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1014924,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=819796k,mode=755) /dev/disk/by-uuid/5166cbb1-8234-4127-bb0b-bbfda1658b68 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1679740k) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) none on /sys/kernel/debug type debugfs (rw,relatime) root@PC# echo module usbserial +p /sys/kernel/debug/dynamic_debug/control bash: /sys/kernel/debug/dynamic_debug/control: Datei oder Verzeichnis nicht gefunden Your kernel is not configured to use dynamic debugging. You need to enable CONFIG_DYNAMIC_DEBUG=y. Johan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130419090445.GB32104@localhost
Bug#704242: Driver for PL-2303 HX not working
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-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130419143923.GC32104@localhost
Bug#704242: Driver for PL-2303 HX not working
On Wed, Apr 17, 2013 at 07:43:11PM +0200, Karsten Malcher wrote: Am 17.04.2013 15:13, schrieb Johan Hovold: Can you minimise your test setup using a custom program which only opens the device, initialises it, writes the four characters (e.g. test) and reads them back (over you hardwired loop) before closing the device again? I have used a little perl program that opens the port and send Test to the looped back device. The length of the log looks good. Great. Now I can see what's going on. The only problem (?) is that everything seems to be working. The write succeeds and the four bytes are read back as they should by the driver. The first thing that comes to mind that could prevent you from reading the received data would be if the tty device is configured for canonical input processing. Have you made sure this is not the case? Can you read the data back if you add a newline to your test string (e.g. test\n)? Make sure to verify it using a working device first. I use this script with a ch341 adapter and it works. Hmmm. Did you remember to initialise the device (e.g. set the termios flags)? Johan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130418093512.GD25860@localhost
Bug#704242: Driver for PL-2303 HX not working
On Thu, Apr 18, 2013 at 12:36:17PM +0200, Karsten Malcher wrote: Am 17.04.2013 15:13, schrieb Johan Hovold: Can you try to reproduce this on a later kernel (e.g. 3.8) which uses dynamic debugging? I have compiled a 3.8.5 kernel now on Debian testing (wheezy). The result is the same as in 3.2.0 ! I could receive only some of the first bytes after opening the port afterwards everything is lost without errors. Can you generate a log where bytes are actually lost? Nothing seemed to get lost in the previous log you posted. How can i enable the debugging in kernel 3.8.5? Make sure debugfs is mounted: mount -t debugfs none /sys/kernel/debug and then enable debugging: echo module usbserial +p /sys/kernel/debug/dynamic_debug/control echo module pl2303 +p /sys/kernel/debug/dynamic_debug/control Johan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130418105618.GE25860@localhost
Bug#704242: Driver for PL-2303 HX not working
On Wed, Apr 17, 2013 at 02:46:23PM +0200, Karsten Malcher wrote: Am 17.04.2013 13:31, schrieb Johan Hovold: The logs there appear not to have debugging enabled in usb-serial core. Please post the logs with debugging enabled in both modules to this thread as well. O.K. Nobody has requested this so far. So this time with both modules in debug-mode: root@PC:# lsmod | grep usb usb_storage43870 0 usbserial 32061 1 pl2303 usbhid 36379 0 hid81288 1 usbhid usbcore 128498 8 ehci_hcd,ohci_hcd,usbhid,usbserial,uas,usb_storage,pl2303 usb_common 12354 1 usbcore scsi_mod 162372 6 libata,sd_mod,sr_mod,sg,uas,usb_storage root@PC:# rmmod pl2303 root@PC:# rmmod usbserial root@PC:# modprobe usbserial debug=1 root@PC:# modprobe pl2303 debug=1 * Then i connected the adapter. * Connect with cutecom and a wired loop with 9600 baud. * Write Test * Close connection * Remove adapter Logs attached. The logs look incomplete. It's probably because they're flooded with serial_write_room and chars_in_buffer messages. Can you try to reproduce this on a later kernel (e.g. 3.8) which uses dynamic debugging? Can you minimise your test setup using a custom program which only opens the device, initialises it, writes the four characters (e.g. test) and reads them back (over you hardwired loop) before closing the device again? Make sure to verify it using a working device first. Thanks, Johan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130417131343.GC25860@localhost
