From owner-freebsd-current Fri Mar 10 09:45:56 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA19689 for current-outgoing; Fri, 10 Mar 1995 09:45:56 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA19680 for ; Fri, 10 Mar 1995 09:45:50 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id DAA05234; Sat, 11 Mar 1995 03:43:19 +1000 Date: Sat, 11 Mar 1995 03:43:19 +1000 From: Bruce Evans Message-Id: <199503101743.DAA05234@godzilla.zeta.org.au> To: bde@zeta.org.au, pete@pelican.com Subject: Re: bad outgoing serial coms Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >> RTS flow control is supposed to work now, so the big buffers should >> be unnecessary (but advisable for speed) if whatever you are connecting >> to supports CTS flow control. >That is not (all of) the problem; my friend here who gets this message >all the time uses rts/cts and at least it works going out. As far as >I know his modems support rts/cts both ways and are config'd right. It wasn't supposed to work in 2.x until 1995/02/24. >> SLIP and PPP don't use clists for input so they don't depend on TTYHOG. >The cited message comes from a place that involves the "raw" clist queue. >There is only one place in the driver that increments the counter >involved... >-------------------------------------------------- > com->delta_error_counts[CE_TTY_BUF_OVERFLOW] > += b_to_q((char *)buf, incc, &tp->t_rawq); >--------------------------------------------------- >I don't know why it might come in slip/ppp if they don't use clists; >are you *sure* they don't use the raw clist queue? Yes, and that code isn't executed except in the standard line discipline. Bruce