Bug 553675 - kernel-level flow control on serial console
Summary: kernel-level flow control on serial console
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Mauro Carvalho Chehab
QA Contact: Cui Chun
URL:
Whiteboard:
Depends On:
Blocks: 502912 600363 719046 726799
TreeView+ depends on / blocked
 
Reported: 2010-01-08 16:22 UTC by Jon Thomas
Modified: 2018-11-14 17:53 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-12 16:45:07 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 621988 0 low CLOSED Hardware flow control on serial console is not functional 2021-02-22 00:41:40 UTC

Internal Links: 621988

Description Jon Thomas 2010-01-08 16:22:07 UTC
A customer has indicated they need kernel-level flow control at ttyS0 level

They have enabled the following:
- in the kernel command line : "console=ttyS0,115200n8r"
- in /etc/inittab : "/sbin/agetty -h ttyS0 115200 vt100-nav"

That apparently works fine for user level, but not kernel level. One issue appears to be that UPF_CONS_FLOW is not set in up->port.flags and so the code never enters:

drivers/serial/8250.c 

  1631		if (up->port.flags & UPF_CONS_FLOW) {
  1632			struct uart_info *info = up->port.info;
  1633			unsigned int msr;
  1634	
  1635			tmout = 1000000;
  1636			while (--tmout) {
  1637				msr = serial_in(up, UART_MSR);
  1638	
  1639				if ((info->flags & UIF_CTS_FLOW) &&
  1640				    (msr & UART_MSR_CTS))
  1641					break;
  1642				else if ((info->flags & UIF_DSR_FLOW) &&
  1643					 (msr & UART_MSR_DSR))
  1644	 				break;
  1645	
  1646				udelay(1);
  1647				touch_nmi_watchdog();
  1648			}
  1649		}
  1650	}

The howto indicates issues that need to be resolved:

http://www.faqs.org/docs/Linux-HOWTO/Remote-Serial-Console-HOWTO.html#BUGS-KERNELP

I believe the patch mentioned is 

http://lkml.indiana.edu/hypermail/linux/kernel/0310.2/1080.html 

but it is old and not in 2.6.33 and I find no sign offs or commits. It doesn't apply cleanly to rhel5.

I'm hoping somebody more knowledgeable in this can look at this issue and see what needs to be done to enable kernel-level flow control.

Comment 14 Mauro Carvalho Chehab 2011-02-09 11:13:52 UTC
Pierre,

It occurred to me that I din't ask a basic question about this BZ: for RTS/CTS flow control to work, the customer needs to have a properly wired cable. There are  several ways to wire serial cables, as shown, for example, at:

http://www.lammertbies.nl/comm/info/RS-232_null_modem.html

A 3-wire cable won't offer hardware level flow control. There are even some ways of wiring the cable that will fake hardware control to the serial interfaces (like the "Null modem with loop back handshaking" wiring schema showed on the above site). With those cables, if the serial application is programmed to use RTS/CTS, it will work, but flow control will fail if needed, as it is not properly wired.

So, the question is: how are their console cables wired?

Comment 17 RHEL Program Management 2011-08-12 16:45:07 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.


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