Date: Wed, 04 Mar 1998 16:46:57 -0800 From: Mike Smith <mike@smith.net.au> To: shimon@simon-shapiro.org Cc: current@FreeBSD.ORG Subject: Re: silo overflows (Was Re: 3.0-RELEASE?) Message-ID: <199803050047.QAA23134@dingo.cdrom.com> In-Reply-To: Your message of "Wed, 04 Mar 1998 16:37:15 PST." <XFMail.980304163715.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> On 05-Mar-98 Mike Smith wrote:
>
> >> There was a time when it didn't happen at all...hmmm was that 2.1R ?
> >> or maybe 2.2-CURRENT sometime after that.
> >
> > Yeah, before the message was actually printed. Let's take all those
> > annoying warning messages out of the kernel, so that you can't tell
> > what is going wrong. It works for Microsoft, after all.
>
> If the ``problem'' is harmless. then do not print it. Make the printing
> optional?
- Harmless problems don't generally warrant (or have) messages.
- The problem that results in this message is not harmless.
- The printing is entirely optional. You have the source.
> > You could try reading the manpage, just for starters.
>
> Do you think I did not? I did and I do not agree with what it says.
Uh, you said that you don't know what the message means. The manpage
tells you. If you read the manpage you can't claim to not know what
the message means. If you are in a position to disagree at all, it can
only be because you believe you know more than the manpage author.
> >> > I though that UARTs and RS-232C were well understood.
> >
> > Na und? They're sufficiently well understood for unrecoverable
> > error conditions to be detected and reported. What more do you want?
>
> Perfection :-) The world, as a whole knows how to never overflow a UART
> for quite some time.
It does? I wish someone had told me, or any of the countless thousands
of people that have spent millions of programmer hours working with
what we obviously mistakenly thought were the fundamentals of
asynchronous serial communications.
> There are transmission errors, of course. These
> either get thrown out, or passed up to the error resilient layer. This is
> particularly valid view in the case of TCP/IP over PPP, which has at least
> two places in which to handle the error.
... neither of which provide a mechanism for in-band signalling of
dropouts. You can argue the merits of this, but you're attempting to
misdirect the topic.
I do not see an Ethernet card
> report error per collision.
This is not a valid comparison; a collision is a recoverable
("harmless") error. You *will* see ethernet drivers (not cards)
reporting unrecoverable errors, which is what a FIFO overrun is.
> This is easy for me to say and agravating for you to read, as I am being
> jugmental over something I had zero contribution for and almost as much
> investigation.
It certainly does wonders for your reputation.
> If it is your opinion that the driver is optimal, and these errors are
> unavoidable, I'll accept this opinion and assume that my impression, as
> expressed above, is erroneous. Really.
The sio driver is about as good as they get; you are welcome to talk to
Bruce Evans (bde@freebsd.org), the principal maintainer of same, and
David Nugent (davidn@freebsd.org), the author of the BNU FOSSIL driver,
if you want some extremely well-respected opinions on the quality of
said code.
Meanwhile, I would suggest that you look at "silo overflow" messages in
their correct light, which is as indicative of a serious interrupt
response problem on your system.
You may find it informative to modify the spl* routines to keep track
of time spent with various interrupt types masked in order to identify
the sorts of activity which lead to these problems.
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're behind. \\ mike@smith.net.au
\\ The race is long, and in the \\ msmith@freebsd.org
\\ end it's only with yourself. \\ msmith@cdrom.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803050047.QAA23134>