Date: Mon, 06 Jun 2005 15:03:25 +0200 From: Bernd Luevelsmeyer <bdluevel@heitec.net> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-bugs@FreeBSD.org, FreeBSD-gnats-submit@FreeBSD.org Subject: Re: kern/81807: Silo overflows with serial multiport cards Message-ID: <20050606130325.1BE54A8916@christel.heitec.net> References: <200506021248.j52CmUV4002914@edgar.admin.er.heitec.net> <20050604211741.X5959@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > > On Thu, 2 Jun 2005, Bernd Luevelsmeyer wrote: > > >> Description: > > The machine has 3 serial 8-port-cards installed, 2 of them ISA cards > > and one PCI card. The card model of all 3 of them is Moxa SmartIO > > C168H (http://www.moxa.com/Product/C168H.htm and > > http://www.moxa.com/Product/C168HPCI.htm). Since Upgrading to > > 5-Stable the ISA cards have high numbers of silo overflows. This did > > not happen with 4-Stable. > > The overflows happened with SCHED_4BSD or SCHED_ULE, with and > > without PREEMPTION in the kernel, and regardless of baudrate (I > > tried 9600 and 115200). Also I tried several HZ values in the kernel > > (100, 1000 and 4000), and it didn't matter. > > > > The machine is a PII with 300 MHz. Now this isn't the most powerful > > (and ISA is a little bit old-fashioned), but the effect happens also > > when only one of the 24 ports is used and it's at 9600 Baud, and > > anyway with 4-Stable there was no problem at all. > > Interrupt handling is bad in -current but not usually that bad. The I'm using -stable, but otherwise I agree. > loss of performance was in the 5-10% range when I tested it a lot on > a 366 MHz Celeron 12-18 months ago. Latency increase is worse than > performance decrease but wasn't noticeable with <= 8 ports at 115200. We've got several machines upgraded from 4-stable to 5-stable, and apart from the serial multiport cards (which are on only one machine) I can confirm this. It's only this one machine that causes trouble. > > Here is the machine's dmesg: > > Everything seems to be set up correctly. sio even handles the isa > ports better that the pci ports. I would have expected silo overflows > to occur for the pci ports first because fast interrupts are not used > for them (try using the PUC_FASTINTR option to fix this). Interrupts > seem to be working at probe time. Do they work later? Use vmstat > or systat -v to check that some keep occurring. Check that fast > interrupts are used by booting with -v. I've had PUC_FASTINTR but switched it off hoping things would improve by that, which they didn't. (AUTO_EOI_1 on or off also doesn't matter, AUTO_EOI_2 on never works.) I've put PUC_FASTINTR back in without any effect, except that fast interrupts are now used for PUC. Interrupts do work generally, it's only that there are not enough of them. Losing bytes only happens when the amount of output is big, such as a screen refresh in "less" or "vim", where I can expect between 2 and 10 lost bytes on a 50-lines-and-80-columns terminal. The output of "ls" in a small directory always comes properly, for example. What did help (found it just now) was to disable acpi by 'hint.acpi.0.disabled="1"' in /boot/loader.conf. Before, the BIOS was discovered to be on the BIOS blacklist, and ACPI disabled automatically. Now, it's not even loaded, and I'm losing way fewer bytes. (The reason is beyond me; after all, acpi was not active before too.) Now there's only occasionally a missing byte, in about 1 out of 20 screen refreshes. Greetings, Bernd
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050606130325.1BE54A8916>