>Number:         3664
>Category:       kern
>Synopsis:       The reworked "com" driver does not work with the Hayes ESP.
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri May 23 18:50:01 1997
>Last-Modified:
>Originator:     Thor Lancelot Simon
>Organization:
TNF
>Release:        NetBSD-1.2E, com.c 1.99
>Environment:
		i386, single-port Hayes ESP v2.1 configured as com2,
		kernel configured with options COM_HAYESP
System: NetBSD guinness 1.2E NetBSD 1.2E (GUINNESS2) #1: Sun May 11 05:31:52 CDT 1997 tls@guinness:/usr/src/sys/arch/i386/compile/GUINNESS2 i386


>Description:
	The recent changes to the "com" driver appear to have broken the
	support for the Hayes ESP in enhanced mode.  On a system which
	functioned correctly under NetBSD/i386 1.2C and previous revisions,
	now the ESP serial port loses data, asserts hardware flow control for
	excessive lengths of time, and sometimes will not transmit certain data
	patterns at all.  The port is probed correctly as an ESP in 1024k FIFO
	mode.  Replacing the ESP card with a 16650 card configured as com2 does
	in fact work around the problem.

>How-To-Repeat:
	Attempt to transfer a large file at 57600 or 115200 bps using an ESP
	as the receiving end.  Notice the garbled packets and other retries
	and the long pauses during which the ESP asserts flow control and thus
	receives no data.  With PPP this manifests itself as low throughput
	(on my machine, approximately 3KB/sec at 115.2Kbps) or even sometimes
	LCP failure; with kermit using 9K packets and a window size of 12, it
	often manifests itself as complete failure to receive any packet after
	the first one.  Kermit with 9K packets is a particularly good way to
	repeat the failure.

>Fix:
	I suspect that the 1K FIFO is not being completely drained.
>Audit-Trail:
>Unformatted: