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

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

[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.
 
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 ? 

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

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

[Jiri Slaby]

On 01/03/2012 04:37 PM, Dave Jones 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.

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.

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

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

regards,
-- 
js
suse labs

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

[Dave Jones]

On Tue, Jan 03, 2012 at 05:00:45PM +0100, Jiri Slaby wrote:
 > On 01/03/2012 04:37 PM, Dave Jones 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.
 > 
 > 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. 

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

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

[Jiri Slaby]

On 01/03/2012 05:13 PM, Dave Jones wrote:
> On Tue, Jan 03, 2012 at 05:00:45PM +0100, Jiri Slaby wrote:
>  > On 01/03/2012 04:37 PM, Dave Jones 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.
>  > 
>  > 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. 
> 
>  > > 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.

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

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

-- 
js
suse labs

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

[Alan Cox]

On Tue, 3 Jan 2012 10:37:07 -0500
Dave Jones <davej@redhat.com> 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.

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

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

[Jiri Slaby]

On 01/03/2012 05:06 PM, Alan Cox wrote:
> On Tue, 3 Jan 2012 10:37:07 -0500
> Dave Jones <davej@redhat.com> 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.
> 
>>  > 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?

-- 
js
suse labs

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

[Chris Elmquist]

On Wednesday (01/04/2012 at 09:54PM +0100), Jiri Slaby 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.
> > 
> >>  > 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

-- 
Chris Elmquist