Date: Thu, 05 Mar 1998 12:37:19 +1030 From: Matthew Thyer <Matthew.Thyer@dsto.defence.gov.au> To: Mike Smith <mike@smith.net.au> Cc: shimon@simon-shapiro.org, current@FreeBSD.ORG Subject: Re: silo overflows (Was Re: 3.0-RELEASE?) Message-ID: <34FE08D7.159A2AD@dsto.defence.gov.au> References: <199803050047.QAA23134@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike,
You're being a bit too agressive with Simon here.
Lets get this thread back on track.
Simon is seeing an error message, so am I. I think many people
are also seeing it.
Now the frequency of this message has changed a lot since the 2.1R
days which would seem to indicate that something can be done
about the processing of interrupts to reduce the occurrance of
FIFO overflows.
This happens a lot as after several hours (2 or 3) of using
ijppp and XFree86 the count of FIFO overflows can be around 100.
Also this problem occurs on many machines Pentium 166, Pentium 100
etc. It does not only occur on 486SX25's or other such low end
machines. (I have a Pentium 166 and a V.FC modem).
Now is it really a problem ?
100 overflows in two hours probably wont make much difference to
throughput so maybe the error message should be suppressed but
that would hide possible future deterioration of interrupt
handling.
I cant do anything about it as I dont have the skills or time.
But maybe it should be seriously discussed.
Mike Smith wrote:
>
> >
> > 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
--
Matthew Thyer Phone: +61 8 8259 7249
Corporate Information Systems Fax: +61 8 8259 5537
Defence Science and Technology Organisation, Salisbury
PO Box 1500 Salisbury South Australia 5108
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?34FE08D7.159A2AD>