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.

(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.

Note

You need to
log in
before you can comment on or make changes to this bug.