From owner-freebsd-hackers Mon Dec 6 11:54:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4819C15129; Mon, 6 Dec 1999 11:54:53 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id JAA17769; Mon, 6 Dec 1999 09:58:59 -0800 Date: Mon, 6 Dec 1999 09:58:59 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mike Smith Cc: hackers@freebsd.org Subject: Re: tty level buffer overflows In-Reply-To: <199912060441.UAA00805@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > > Er, you should read the sio(4) manpage too. tty-level buffer overflows > > > have nothing to do with interrupt latency/execution time. > > > > You mean this: > > > > sio%d: tty-level buffer overflow. Problem in the application. Input has > > arrived faster than the given module could process it and some has been > > lost. > > Yup. Ignore the "problem in the application" part, as that predicates > that the kernel and driver are working properly, which doesn't seem to be > the case. The problem here is that the buffer between the top side of > the driver and the application isn't being drained fast enough. It would > be educational to know what the app is sleeping on when these messages > are emitted; just dropping to ddb and using 'ps' would probably be > enough. There has to be some reason that the process is either not being > woken when data arrives, or is being held up somewhere else for long > enough that the clist overflows. That's tough because it's transitory and hard to notice as I only rlogin into this machine! Sounds to me a gdb breakpoint is what's needed, but this is difficult to do for this machine. > Does the problem still manifest with the recent scheduler changes? > Perhaps the comms processes are being unfairly scheduled against for some > reason? The kernel is a November 12 kernel. Maybe it's better now. However, I'm still staggering under the recent bdev changes - when everything has settled down and all my other freebsd machines can boot all the way up and are all up to date, I'll revisit this. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message