From owner-freebsd-hackers  Thu Aug 19  9:10:27 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22])
	by hub.freebsd.org (Postfix) with ESMTP id 6AE2F14C37
	for <hackers@freebsd.org>; Thu, 19 Aug 1999 09:10:14 -0700 (PDT)
	(envelope-from bmcgover@bmcgover-pc.cisco.com)
Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA09341 for <hackers@freebsd.org>; Thu, 19 Aug 1999 12:09:28 -0400 (EDT)
Received: from bmcgover-pc.cisco.com (localhost.cisco.com [127.0.0.1])
	by bmcgover-pc.cisco.com (8.9.3/8.9.3) with ESMTP id MAA00362
	for <hackers@freebsd.org>; Thu, 19 Aug 1999 12:09:27 -0400 (EDT)
	(envelope-from bmcgover@bmcgover-pc.cisco.com)
Message-Id: <199908191609.MAA00362@bmcgover-pc.cisco.com>
To: hackers@freebsd.org
Subject: sio doesn't do HW flow correctly?!?
Date: Thu, 19 Aug 1999 12:09:27 -0400
From: Brian McGovern <bmcgover@cisco.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I thought I'd give people a chance to jump on this before I opened a PR on it.

I'm currently using a Cyclades board at 115200 to talk to my PII laptop with
a 16550A UART on board via a null modem cable. I'm trying to run PPP over the 
link with crtscts set, although I see the same problems using programs 
other than PPP.

I stuck a printf() at line 2113 of /usr/src/sys/i386/isa/sio.c to see if
CRTS_IFLOW was being turned on, whereas CRTS_IFLOW is the input half of 
crtscts.

I managed to get the printf, so I'm assuming that sio is being advised to do
RTS input flow control.

However, when I start running data, I get silo overflows. Sometimes its more
frequent than others, but its enough to keep most of the packets from going
through the link. 

I have a breakout box on the line, as well as detectors in the Cyclades driver
for sensing line state change, and RTS never drops on the 16550A. It just
happily overflows.

I realize that 99% of the time, sio is used with a modem. Therefore, also being
a modem tester, I realize that its rare to completely saturate a 115200bps link
between the modem and the UART in the PC (we have exactly one test case with
highly-compressible data where this happens reliably), so I suspect that this
problem may go unnoticed in many cases, simply because you don't fill the FIFO.

I also went so far as to check individual RS232 signals via TIOCMSET to make
sure that the port functioned as commanded. It did so.

So, I suspect the problem is that the driver is not correctly driving flow
control.

I will therefore start to dive in to the problem to isolate it. However, I
figured I'd give everyone a chance to comment before I filed a PR.
	-Brian


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message