Date: Sat, 1 May 2004 14:38:19 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: othermark <atkin901@yahoo.com> Cc: freebsd-current@FreeBSD.org Subject: Re: sio: lots of silo overflows on Asus K8V with Moxa Smartio C104H/PCI Message-ID: <20040501142328.E19558@gamplex.bde.org> In-Reply-To: <c6u3nd$f8q$1@sea.gmane.org> References: <20040426111754.38a855c4.bm@malepartus.de> <20040426233925.Y5300@gamplex.bde.org><c6u3nd$f8q$1@sea.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 30 Apr 2004, othermark wrote: > Burkard Meyendriesch wrote: > > ... > > Meanwhile I plugged the Moxa board into another PCI slot of my motherboard > > and the conflict with the ata6 interrupt seems to be solved. The silo > > over- flows are still there. > > > > By the way: How should I set the BIOS parameters "PCPI 2.0 yes/no" and > > "ACPI APIC yes/no"? Do they have anything to do with the PCI interrupt > > behaviour? > > I had to enable APIC to get my puc supported card to work. W/o it the > interrupts were shared and I received a ton of silo overflows and lost data > on line. There must be bugs elsewhere for shared interrupts to cause lots of slo errors. Try my patch in other mail to avoid Giant lossage. I forgot to mention that a larger unwritten patch is also needed to fix sio's interrupt priority for the shared case (all tty interrupts get the low priority PI_TTYLOW, but most or all hardware ones should have priority PI_TTYHIGH, and drivers that prefer to use a fast interrupt should get priority higher than the current highest priority (PI_REALTIME). > so try the following in your kernel and rebuild > > options COM_MULTIPORT COM_MULTIPORT is only needed for old isa-ish multiport cards. It is not needed for cards supported by puc, and has large overheads so it shouldn't be used when not needed. > options PUC_FASTINTR This may be critical here. But don't use it if the port is actually shared with a device whose driver doesn't support fast interrupts. Then it will either have no effect or will break the attachment of the other device, depending on which device is attached first. > device apic He must already have this to get irq19. "device apic" may also cause silo overflows. See my other reply. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040501142328.E19558>