I recently upgraded to ubuntu 12.04 from 10.04. Under 10.04 I had no trouble using usbserial driver to connect to a device through the serial port. After the upgrade usually I cannot reset the baud rate: it is initialized to 9600, but my device needs 115200. When I try to reset the speed I get: $ sudo stty -F /dev/ttyUSB0 speed 9600 baud; line = 0; -brkint -imaxbel $ sudo stty -F /dev/ttyUSB0 115200 stty: /dev/ttyUSB0: unable to perform all requested operations $ sudo setserial -av /dev/ttyUSB0 Cannot get serial info: Invalid argument $ ls -l /dev/ttyUS. crw-rw- 1 root dialout 188, 0 Nov 26 10:21 /dev/ttyUSB0 crw-rw- 1 root dialout 188, 1 Nov 26 10:21 /dev/ttyUSB1 The oddest thing is that I have gotten this to work on occasion. The first time I rebooted the system, and it worked. After a shutdown it had the same problem and rebooting did not work, but reloading the driver did.
Unfortunately this has not worked since: $ sudo modprobe -r usbserial $ sudo modprobe usbserial vendor=0x0403 product=0x6001 $ sudo stty -F /dev/ttyUSB0 115200 stty: /dev/ttyUSB0: unable to perform all requested operations. USB to serial devices like the Prolific or FTDI series don't follow any official specification. Instead, they use two bulk endpoints (one for output, one for input) with specific vendor-specific control messages used to configure things like baudrate. Thus, it's not too much of a surprise if something like the generic usbserial driver has trouble setting baudrates or doing other configuration tasks on a FTDI chip. As you noticed, using ftdisio will work much better. Even 10.04 should be loading ftdisio by default, as ftdisio has been hardcoded to handle 4003:6001 (FT232) devices for nearly as long as Ubuntu has existed.
My guess is that you were loading two drivers that were both registered to handle 4003:6001 - one by design, one due to your module parameters. Changing your kernel or even the phase of the moon could mean that one happens to get loaded before the other - and if usbserial gets loaded first, you will not be able to set baudrate.
You should remove your manual usbserial configuration, and let ftdisio handle the device. It will work on both 10.04 and 12.04. I think I found the solution to this, in case anyone googles it in the future.
Gibson Vintage Serial Info
My 10.04 did not load usbserial by default, so I had to do it with modprobe usbserial vendor=0x0403 product=0x6001, which I added to /etc/modules. After I upgraded, my 12.04 loads the ftdisio driver by default, which is for the embedded device I am using. I didn't change my /etc/modules back, so usbserial was being loaded too, and probably causing some sort of conflict. I removed usbserial from /etc/modules and rebooted, and it worked.
If I were really confident in this solution I would confirm it by rebooting my machine again and seeing if the serial port came up properly - but I would feel pretty silly if I rebooted and lost the connection, since I do need to get work done while I have it.
Mac Serial Info
So, I have a board with 6 hardware serial ports: the first 2 on the ETX bus and the last 4 on the ISA bus. A couple of things strike me about what I see in your /proc and dmesg output:. You shouldn't try to share an IRQ between devices. It may work, but the intention with ISA is that each device on the bus that needs an interrupt line to work gets its own IRQ. If your serial port cards don't give you enough IRQ options, you may simply not be able to use them all together in that PC. The I/O addresses you are using for the second pair of serial ports are nonstandard. TtyS2 is normally at 0x3E8 and ttyS3 is normally at 0x2E8.
I would move those if you have that option with the serial card. (There are no standard I/O addresses or IRQs for ttyS4 and up.) Aside from all that, if I needed 6 serial ports on a Linux box, I wouldn't try to use plain old serial port adapter cards. I would use something like a. They still offer one that will work in your ISA slots, the Xe model. If you need cheap, you should be able to find one floating around on the used market; they were very popular back in the day.
I know this question was posted in March 2011, but I encountered the same problem on Debian recently, but have found the relatively obscure cause/solution. As I'm sure you know, increasing the number of /dev/ttySX serial devices beyond the default of four (/dev/ttyS0 through ttyS3) is easiest done with a boot flag in grub (as changing the default requires recompiling the kernel) After booting these new ttyS devices are empty (Port, IRQ, UART etc values are all set to zero). After experimenting here, it turns out the reason is you're trying to configure a port with a zero base baud. Unfortunately, it starts off as zero.
However, when you try to change a port without specifying the base baud, it is possible for the port to become 'usable' and unless we enforce the 'must not have zero base baud' rule we have the possibility to oops the kernel via a divide by zero. What you must do is specify the basebaud value before you do anything else. If I recall correctly, basebaud 115200 worked for me. In addition to basebaud as mentioned in my other answer on this question, it may also be the order of arguments: (I didn't have time to experiment with different orders to see what exactly fixed it, as basebaud definitely worked) I ran into a similar set of issues trying to get new serial ports installed into an embedded x86 application. The issue for me turned out to be that the setserial program converts its command line arguments, in order, into corresponding ioctl operations to set the various device parameters. Basically, setserial applied a strategy of: 1)read the current setting for the specific /dev/ttySx 2)modify the values as specifid by each command line arg, with each individual command line argument or flag turning into an ioctl So, specifying the uart type (or autoconfigure) before you specify the port or irq won't work correctly for ports greater the /dev/ttyS3, because the port value for /dev/ttyS3 isn't initialized to anything. This causes the ioctl operation to return with errno set to EINVAL (invalid argument).
Serial Info
I suspect the chain of ioctl's that ^fourport flag followed by lowlatency flag turn into something that doesn't make sense to the driver.