In message <[EMAIL PROTECTED]> Mike Smith writes:
: 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.
:
: Does the problem still manifest with the recent scheduler changes?
: Perhaps the comms processes are being unfairly scheduled against for some
: reason?
We're seeing it with our ppp link, which uses the kernel level ppp
code. Since it doesn't happen for me often, it is hard to diagnose.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
