Bug 771010 - serial ports now asserting DTR and RTS during boot; breaks connected hardware
serial ports now asserting DTR and RTS during boot; breaks connected hardware
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: ModemManager (Show other bugs)
16
i686 Linux
unspecified Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-30 22:19 EST by Chris Elmquist
Modified: 2013-02-13 08:50 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-13 08:50:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Chris Elmquist 2011-12-30 22:19:29 EST
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);
Comment 1 Dave Jones 2012-01-03 11:25:50 EST
I posted about this upstream. https://lkml.org/lkml/2012/1/3/109

Alan Cox has some interesting suggestions.
Comment 2 Chris Elmquist 2012-01-03 11:47:51 EST
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.
Comment 3 Dave Jones 2012-01-03 12:37:48 EST
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.
Comment 4 Chris Elmquist 2012-01-04 17:57:48 EST
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.
Comment 5 Dave Jones 2012-01-04 18:06:56 EST
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.
Comment 6 Chris Elmquist 2012-01-04 18:30:07 EST
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.
Comment 7 Dan Williams 2012-07-20 18:17:20 EDT
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.
Comment 8 Chris Elmquist 2012-07-21 12:51:08 EDT
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"
Comment 9 Bill Alexander 2012-12-01 20:54:45 EST
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"
Comment 10 Fedora End Of Life 2013-01-16 08:09:37 EST
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
Comment 11 Fedora End Of Life 2013-02-13 08:50:42 EST
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.

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