Description of problem: The RI serial status line for a USB to Serial adapter with an (apparently) older Prolific PL2303 chipset is not supported - it appears as permanently asserted (SET). (The other input status lines CD, DSR, and CTS are properly supported.) Version-Release number of selected component (if applicable): Linux version 2.6.18-1.2868.fc6 (but also was a problem with earlier kernels, e.g., FC-3, final kernel update.) The USB to Serial adapter tested with this chipset is the Sabrent SBT-USC1M. http://www.sabrent.com/products/specs/SBT-USC1M.htm purchased from ByteRunner as their SKU: CBL-USB-CS1B http://www.byterunner.com/byterunner/category=USB+to+Single+Serial+Adapters/exact_match=exact How reproducible: Always, for this particular Prolific chipset version. The attached test program "adapter_test.c" toggles the DTR output status line and monitors the state of the four input status lines, one or more of which is assumed to be jumpered to the DTR line. Steps to Reproduce: 1. Compile the attached test program : $ cc -Wall adapter_test.c -o adapter_test 2. Plug the USB to Serial adapter into a USB port on the PC. Verify the assigned device port by running 'dmesg'. E.g., /dev/ttyUSB0 3. Connect a jumper between the DTR and RI pins (DB-9 pins 4 and 9) on the adapter. Optionally additionally jumper the DTR pin to the CD, DSR, and CTS input pins (pins 1, 6, and 8). 4. Run the test program: $ ./adapter_test /dev/ttyUSB0 Actual results (with all four input status pins jumpered to DTR): Jumpered pin 4 to 9 1 6 8 Status Line: DTR => RI CD DSR CTS --- --- --- --- --- clr => SET clr clr clr SET => SET SET SET SET clr => SET clr clr clr SET => SET SET SET SET Expected results: Jumpered pin 4 to 9 1 6 8 Status Line: DTR => RI CD DSR CTS --- --- --- --- --- clr => clr clr clr clr SET => SET SET SET SET clr => clr clr clr clr SET => SET SET SET SET Additional info: USB to Serial adapters with an apparently later version of the Prolific PL2303 perform properly as expected, e.g., the ByteRunner SKU Y-105. Sabrent did not respond to my request for the specific Prolific chipset version in their product, however the Sabrent adapter appears to use the same Prolific chipset as an adapter purchased in mid-2004 from Sewell Development Corp, for two reasons: 1. Both have basic support under the Linux 2.4 kernel (newer PL2303 chipsets aren't supported by the 2.4 kernel). 2. Both exhibit the same RI problem. Sewell describes the chipset change in their adapter in Oct 2004 from the PL2303 to the PL2303HX here: http://sewelldirect.com/UsbToSerialSupportLinux.asp Output from dmesg when adapter is plugged into the USB port: ------------------ usb 1-2: new full speed USB device using uhci_hcd and address 3 usb 1-2: configuration #1 chosen from 1 choice pl2303 1-2:1.0: pl2303 converter detected usb 1-2: pl2303 converter now attached to ttyUSB0 ------------------- Note: Under kernel 2.4 (Red Hat 9, final update) support for both the Sybrent and Sewell adapter Prolific chipsets was limited to the RX, TX, DTR, and RTS lines. None of the four input status lines respond at all to the test described above, i.e., the test program displays 'clr' for these lines regardless of the state of the DTR line.
Created attachment 144211 [details] USB to Serial adapter status line test program.
(This is a mass-update to all current FC6 kernel bugs in NEW state) Hello, I'm reviewing this bug list as part of the kernel bug triage project, an attempt to isolate current bugs in the Fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug, however this version of Fedora is no longer maintained. Please attempt to reproduce this bug with a current version of Fedora (presently Fedora 8). If the bug no longer exists, please close the bug or I'll do so in a few days if there is no further information lodged. Thanks for using Fedora!
The bug persists in kernel 2.6.22-14, the latest to which I have access. It most probably persists in the current kernel, however I have no HDD space available to install Fedora 8 right now to test it. Since there's been neither activity nor apparent interest in this bug by others since I filed this report over 1 year ago, we might as well close it.