Description of problem: After upgrade from FC14 to FC16, it was discovered that during kernel boot, the DTR and RTS signals of serial devices (both real UART and FTDI USB devices) are being asserted from driver load to approx 20 seconds afterward. This causes some types of hardware connected to these ports to fail as they expect a different sequence or controlled activation of these signals. In particular, ham radio equipment that uses these signals to key transmitters is now going into uncontrolled transmit for nearly the duration of kernel boot. Version-Release number of selected component (if applicable): Fedora 16, kernel 3.1.6-1.fc16.i686.PAE How reproducible: 100% reproducible at every boot Steps to Reproduce: 1. connect RS232 breakout box to serial port 2. boot system 3. watch DTR and RTS LEDs light as kernel is booting Actual results: LEDs light and stay light for almost entire boot duration indicating that DTR and RTS are asserting as the kernel boots. Expected results: DTR and RTS should not activate while kernel is booting. They should only activate when the port is opened by an application and it has performed a termios function to enable these signals. Additional info: The following code in the ftdi_sio driver is one suspect but this behavior happens on 8250 UARTs also so it is systemic now, ftdi_sio.c, line 2161, /* Ensure RTS and DTR are raised when baudrate changed from 0 */ if (!old_termios || (old_termios->c_cflag & CBAUD) == B0) set_mctrl(port, TIOCM_DTR | TIOCM_RTS);
I posted about this upstream. https://lkml.org/lkml/2012/1/3/109 Alan Cox has some interesting suggestions.
So I did the following experiment-- I built my own ftdi_sio driver with a different name that has the above code commented out. ie, it does not assert DTR and RTS when the baudrate is changed to B0 I blacklisted the stock ftdi_sio driver I force my custom ftdi_sio driver to load via a simple script in, /etc/sysconfig/modules/ and the result is my desired behavior-- ie, DTR and RTS are not asserted while the system is booting. Later functioning of DTR and RTS by application software works as expected. I can try to investigate kernel vs userspace (udev, init) issues that may affect this.
as you're able to build your own kernels etc without hand-holding, it might be best if you just post in the linux-kernel thread I mentioned above, and cut out me as middle-man. We can pull in any kernel changes that upstream comes up with once things are worked out.
per discussion via email, it was suggested that removing ModemManager might resolve this issue and it indeed appears to do so on 8250 UART ports. I have to further test on FTDI USB->serial ports to ensure my issue is completely resolved but it looks promising and makes sense. I will follow up once I am able to complete my testing on an FTDI interface. Therefore this does appear to be resolvable in user space and not require driver changes.
glad to hear you found out what was causing the problem. We should probably reassign this to modem-manager in the hope that it can do something that is less hostile to non-modem devices, so that things "just work" without you needing to remove stuff when you eventually reinstall.
agreed. it was certainly unexpected behavior after the FC14->FC16 upgrade. In my case the system being upgraded is used to run my amateur radio (ham) station and I discovered that when I rebooted, my transmitter was being keyed unexpectedly, transmitting an open mic and therefore any audio going on in the room. At the time of discovery, Toby Keith's "Red Solo Cup" was playing loudly. Not cool and not the kind of thing to transmit on amateur frequencies ;-) Needless to say, I only made this mistake once.
ModemManager has udev rules to allow blacklisting of certain drivers or devices. Specifically /lib/udev/rules.d/77-mm-pcmcia-device-blacklist.rules and /lib/udev/rules.d/77-mm-usb-device-blacklist.rules, and for platform devices, /lib/udev/rules.d/77-mm-platform-serial-whitelist.rules. Depending on your device, we could add the rule upstream. One problem with generic USB -> Serial converter drivers is that quite a few modems just have the generic converter chip (often the pl2303 or cp210x) stuck in front of the modem, so we have no idea if it's a modem or a Braille terminal or whatever. So we can't automatically blacklist these types of converters. And then of course you have stuff like http://hackaday.com/2012/04/06/gsm-modem-means-wireless-serial-connections/ where it's a modem off an FTDI chip :( In any case, feel free to blacklist your device in /lib/udev/rules.d/77-mm-usb-device-blacklist.rules, or put a copy of that file with your modifications in /etc/udev/rules.d (so that it doesn't get overwritten on update) and let us know how it goes.
Thank you Dan. I have indeed created a device blacklist rule file which is additionally based on the serial number of the FTDI device and so this constrains it to just this specific box. I realize this is not a generic solution for everyone but solves it very effectively for me. Perhaps some tool could be created which produces a list of devices modem manager might care about and the user can select/deselect them to be "managed" or not?? I created /lib/udev/rules.d/77-mm-usb-ham-blacklist.rules with the following content, ACTION!="add|change", GOTO="mm_usb_ham_blacklist_end" SUBSYSTEM!="usb", GOTO="mm_usb_ham_blacklist_end" ENV{DEVTYPE}!="usb_device", GOTO="mm_usb_ham_blacklist_end" # MicroHAM USB Interface III ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A4014O5N", ENV{ID_MM_DEVICE_IGNORE}="1" LABEL="mm_usb_ham_blacklist_end"
Can we also have the West Mountain Radio Rigblaster PnP added to this blacklist? It suffers from the exact problem. A serial number should not be required, as the vendor has a unique id for the product. # West Mountain Radio Rigblaster PnP ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="814a", ENV{ID_MM_DEVICE_IGNORE}="1"
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.