> >
> > > 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
