serial ports now asserting DTR and RTS during boot; breaks connected hardware

DISCUSSION Dave Jones 4 participants 7 messages Jan 3, 2012 – Jan 4, 2012

Share & tools

Dave Jones

author

2012-01-03 15:37 UTC #0 lore raw

Jiri,
We got this report from a user who notes a change in behaviour for his serial hardware over the last few kernel versions.

https://bugzilla.redhat.com/show_bug.cgi?id=771010

This sounds like it might be related to your DTR/RTS changes back in March 2011 maybe ?

Quoted 40 lines

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.
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);

Jiri Slaby

2012-01-03 16:00 UTC #1 lore raw

Quoted 3 lines · Dave Jones

Jiri,
We got this report from a user who notes a change in behaviour for his serial hardware over the last few kernel versions.

Hi!

I'm busy right now, however just after a quick look, it may be related to:
https://lkml.org/lkml/2011/12/6/573

I'll take a look later.

Quoted 3 lines

https://bugzilla.redhat.com/show_bug.cgi?id=771010
This sounds like it might be related to your DTR/RTS changes back in March 2011 maybe ?

What changes do you mean? In serial-core.c? That one is not used by USB serials. Hence this wouldn't occur with FTDI.

Quoted 33 lines

Quoted 33 lines
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.
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,

Quoted 9 lines

Quoted 7 lines

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);

regards,

Signature · 2 lines

js
suse labs

Dave Jones

author

2012-01-03 16:13 UTC #2 lore raw

Quoted 11 lines · Jiri Slaby

Quoted 3 lines · Dave Jones
Jiri,
We got this report from a user who notes a change in behaviour for his serial hardware over the last few kernel versions.
Hi!
I'm busy right now, however just after a quick look, it may be related to:
https://lkml.org/lkml/2011/12/6/573
I'll take a look later.

thanks. I'll dig a little deeper.

Quoted 6 lines

Quoted 3 lines
https://bugzilla.redhat.com/show_bug.cgi?id=771010
This sounds like it might be related to your DTR/RTS changes back in March 2011 maybe ?
What changes do you mean? In serial-core.c? Thaat one is not used by USB serials. Hence this wouldn't occur with FTDI.

yeah, 303a7a1199c20f7c9452f024a6e17bf348b6b398 and c7d7abff40c27f82fe78b1091ab3fad69b2546f9 jumped out at me, as they were they only things that changed DTR/RTS handling (at least mentioned in changelog) in recent times.

The user mentions that it also affects 8250, though your point may mean that this is caused by something further up in the serial/tty code.

Dave

Jiri Slaby

2012-01-04 18:44 UTC #3 lore raw

Quoted 17 lines · Dave Jones

Quoted 11 lines · Jiri Slaby
Quoted 3 lines · Dave Jones
Jiri,
We got this report from a user who notes a change in behaviour for his serial hardware over the last few kernel versions.
Hi!
I'm busy right now, however just after a quick look, it may be related to:
https://lkml.org/lkml/2011/12/6/573
I'll take a look later.
thanks. I'll dig a little deeper.
Quoted 2 lines
Quoted 2 lines
https://bugzilla.redhat.com/show_bug.cgi?id=771010

Quoted 8 lines

Quoted 4 lines
Quoted 1 line
This sounds like it might be related to your DTR/RTS changes back in March 2011 maybe ?
What changes do you mean? In serial-core.c? Thaat one is not used by USB serials. Hence this wouldn't occur with FTDI.
yeah, 303a7a1199c20f7c9452f024a6e17bf348b6b398 and c7d7abff40c27f82fe78b1091ab3fad69b2546f9 jumped out at me, as they were they only things that changed DTR/RTS handling (at least mentioned in changelog) in recent times.

Rollback. The two commits are about uart. So they don't as well affect FTDI.

Quoted 2 lines

The user mentions that it also affects 8250, though your point may mean that this is caused by something further up in the serial/tty code.

Or userspace. Try what Alan suggested. And ensure that FTDI is really affected. Sometimes bug reporters do mistakes.

Signature · 2 lines

js
suse labs

Alan Cox

2012-01-03 16:06 UTC #4 lore raw

In reply to Dave Jones

Quoted 7 lines · On Tue, 3 Jan 2012 10:37:07 -0500 Dave Jones <[email protected]> wrote:

Jiri,
We got this report from a user who notes a change in behaviour for his serial hardware over the last few kernel versions.
https://bugzilla.redhat.com/show_bug.cgi?id=771010
This sounds like it might be related to your DTR/RTS changes back in March 2011 maybe ?

Looks like your userspace to me at first glance.

ftdi_sio sets up the modem lines in set_termios. Set_termios is called from ftdi_open. ftdi_open is triggered by userspace.

Quoted 2 lines

Quoted 2 lines
The following code in the ftdi_sio driver is one suspect but this behavior happens on 8250 UARTs also so it is systemic now,

Likewise 8250 sets up the lines in serial8250_startup. This is called via uart_startup which is called via open.

I think a necessary first step would be to test a current kernel on FC14, or boot a sane simple kernel and test image and see what that does so all the udev and system startup stuff can be eliminated. Wouldn't surprise me at all however if something like udev triggered poking around for UPS devices or 3G modems wasn't the trigger ?

Alan

Jiri Slaby

2012-01-04 20:54 UTC #5 lore raw

Quoted 13 lines · Alan Cox

Quoted 7 lines · On Tue, 3 Jan 2012 10:37:07 -0500 Dave Jones <[email protected]> wrote:
Jiri,
We got this report from a user who notes a change in behaviour for his serial hardware over the last few kernel versions.
https://bugzilla.redhat.com/show_bug.cgi?id=771010
This sounds like it might be related to your DTR/RTS changes back in March 2011 maybe ?
Looks like your userspace to me at first glance.

Quoted 8 lines

ftdi_sio sets up the modem lines in set_termios. Set_termios is called from ftdi_open. ftdi_open is triggered by userspace.
Quoted 2 lines
Quoted 2 lines
The following code in the ftdi_sio driver is one suspect but this behavior happens on 8250 UARTs also so it is systemic now,
Likewise 8250 sets up the lines in serial8250_startup. This is called via uart_startup which is called via open.

Ok, let's apply the cut&paste rule. Does uninstalling ModemManager fix the issue?

Signature · 2 lines

js
suse labs

Chris Elmquist

2012-01-04 22:37 UTC #6 lore raw

Quoted 13 lines · Jiri Slaby

Quoted 13 lines
Quoted 7 lines
Jiri,
We got this report from a user who notes a change in behaviour for his serial hardware over the last few kernel versions.
https://bugzilla.redhat.com/show_bug.cgi?id=771010
This sounds like it might be related to your DTR/RTS changes back in March 2011 maybe ?
Looks like your userspace to me at first glance.
ftdi_sio sets up the modem lines in set_termios. Set_termios is called from ftdi_open. ftdi_open is triggered by userspace.

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
The following code in the ftdi_sio driver is one suspect but this behavior happens on 8250 UARTs also so it is systemic now,
Likewise 8250 sets up the lines in serial8250_startup. This is called via uart_startup which is called via open.
Ok, let's apply the cut&paste rule. Does uninstalling ModemManager fix the issue?

I'm going with 'cut' :-)

Indeed, removing ModemManager fixes the issue. I removed it, rebooted, and on an 8250 UART port, I never saw DTR or RTS assert during boot.

I'm not currently able to verify on an FTDI interface as I had a hardware failure that has taken it offline (this is the actual radio interface that was originally affected) but I will verify that soon once the hardware is back online.

Note that if you 'yum remove' ModemManager it wants to take NetworkManager out with it due to dependancy... which doesn't seem cool. I removed it with 'rpm' and --nodeps. Probably better to disable it the correct way which I am still learning due to the systemd/chkconfig changeover which has slowed me down a bit.

Thanks guys. I think this will resolve the issue for me once I verify on FTDI hardware.

Chris

Signature · 1 line

Chris Elmquist