Basically I can read from the device, using the pl2303.o module, but I am unable to write to it. I checked the permissions on /dev/ttyUSB0 and /dev/ttyUSB1 but those all were good, and I even went as far to make them rwx to all groups, still no dice. I am using a 2.4 kernel, and am not sure where to go from here.

Anyone have some ideas?

What are you using with which to read and write? If your own code, please post the relevant parts here (in [C O D E] tags please). Otherwise, have you tried to use a standard serial cmmunications tool such as minicom or C-Kermit?
--- rod.

I have tried writing to it with echo and minicom, neither want to work. Basically I am trying to SSH to a box running 2.4.20 kernel and use a serial connection to control another device. The reason I am using USB-Serial converters is to access a multitude of devices on different ports. But more to the point, yes I tried minicom and it failed at writing, but I can read everything the device says when booting.

What does 'failed at writing' look like? Silently not sending? Reporting permission or other error? Are you sure your cabling is correct? Tried looping Tx back into Rx? Is the USB subsystem fully functional on the serial-USB host? If you are a programmer, try running some of the example code from the Serial Programming HOWTO. Add some code to verbosely report all system call return codes.
Are there options of any sort passed to the driver module? If yes, are you sure they are correct?

Upon reading your original post, I see that I made an assumption that you were able to read from it. Was I correct in that assumption?


--- rod.

Alright, well when you connect and reboot the device it will spit back all the BIOS information, and then when it gets to the console where it waits for commands I am unable to send anything. If I type it doesn't show up (obviously this can be fixed with local echo turned on) and won't send to the device. The cabling is correct, as I can read but not write. The permissions ttyUSB0 and ttyUSB1 are also correct for writing. As for the options passed to the module, I am not sure if there are any...

Okay, so your USB-serial interface is used to connect to some device which provides an interactive console type of interface, and when that device reboots (not the USB-serial device), you are able to see its serial output in your minicom session? Have I interpreted that correctly? That confirms only that the receive cabling is correct. Since the device driver is evidently satisfied that it is receiving data from your userspace program (it doesn't hang or produce errors), it must think that it is sending your data. Do you have a pinout for the serial side of the interface? If it is a standard D-sub connector, you can probably loopback the Tx pin (the device under test), to the Rx pin, the known good device. This is probably do-able with a paper clip or other piece of wire. You should do this as closely as possible to the USB-serial interface, to eliminate cabling problems. If you get an echo, you know the software and USB-serial interface are working. If not, then either the serial interface or the driver are not working. If the loopback test is successful, then trace out the cables, and see how that fails. I assume that you have successfully communicated with your external device by other, more conventional means, and it is known that this is not the problem. Another possible issue would be hardware handshaking. Perhaps the driver is not sending data because it has not seen some expected condition of modem control signals on the serial port. Do you know what state these are in? Perhaps you could try using the interface with an external modem, using a fully populated serial cable, and see how that behaves.

--- rod.

It may be that when the bios finishes it changes the baud rate, I have some embedded OS devices that do this. Exit minicom and reconfigure with another baud rate, your boot up will be jibberish but hiting the "enter" key when all activity stops brings up the remote device command prompt. Worth a try anyway.