Date: Wed, 04 Mar 1998 18:48:36 -0800 From: Mike Smith <mike@smith.net.au> To: "Evan Champion" <evanc@synapse.net> Cc: "Matthew Thyer" <Matthew.Thyer@dsto.defence.gov.au>, "Mike Smith" <mike@smith.net.au>, shimon@simon-shapiro.org, current@FreeBSD.ORG Subject: Re: silo overflows (Was Re: 3.0-RELEASE?) Message-ID: <199803050248.SAA23631@dingo.cdrom.com> In-Reply-To: Your message of "Wed, 04 Mar 1998 21:21:37 EST." <053601bd47dd$6cedf300$c9252fce@cello.synapse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> >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. > > I have a Pentium Pro 200 with 16650's (and the 16650's are detected) and > during a full install of FreeBSD over 128kbps ISDN (230.4kbps port speed) I > would get around 700 FIFO overflows. Someone would have to do a lot of > convincing to get me to believe the driver is working properly when a > machine like that can't handle a 128kbps datastream in single user mode... Uh, the driver works just fine. However the driver has no say in the matter when _someone_else_ disables interrupts for a long period of time, or when the hardware fails to deliver them in the first place. If you have a solution to this really quite challenging problem, I'm sure we'd all be delighted to hear about it. Until then, please believe me that there is nothing wrong with the driver, per se., which "causes" these overflows. Just incidentally, the P6 has relatively poor I/O performance, particularly when it comes to talking to ISA peripherals. -- \\ 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?199803050248.SAA23631>