Re: sio: lots of silo overflows on Asus K8V with Moxa Smartio C104H/PCI

On Fri, 30 Apr 2004, Burkard Meyendriesch wrote:

> On Mon, 26 Apr 2004 23:48:46 +1000 (EST) Bruce Evans wrote:
>
> > On Mon, 26 Apr 2004, Burkard Meyendriesch wrote:
> >
> > > on my Asus K8V with Moxa Smartio C104H/PCI I get lots of silo
> > > overflows when backing up my Palm over a serial line, even at 19.200
> > > baud.
> > >
> > > What's going wrong here? And what can I do?
> > > ...
> >
> > You seem to have trimmed too much from the boot messages (I trimmed
> > the rest).  sio5 is not there.
> > ...
> Sorry, I forgot to send the sio's boot message (I forgot it because it
> didn't say anything in boot -v mode). Here are the boot messages:
>
> Apr 30 10:13:38 Reineke kernel: puc0: <Moxa Technologies, Smartio C104H/PCI> port 0xa000-0xa00f,0xa400-0xa43f,0xa800-0xa87f irq 19 at device 14.0 on pci0
> Apr 30 10:13:38 Reineke kernel: puc0: Reserved 0x40 bytes for rid 0x18 type 4 at 0xa400
> Apr 30 10:13:38 Reineke kernel: sio4: <Moxa Technologies, Smartio C104H/PCI> on puc0
> Apr 30 10:13:38 Reineke kernel: sio4: type 16550A
> Apr 30 10:13:38 Reineke kernel: sio4: unable to activate interrupt in fast mode - using normal mode
> Apr 30 10:13:38 Reineke kernel: sio5: <Moxa Technologies, Smartio C104H/PCI> on puc0
> Apr 30 10:13:38 Reineke kernel: sio5: type 16550A
> Apr 30 10:13:38 Reineke kernel: sio5: unable to activate interrupt in fast mode - using normal mode
> Apr 30 10:13:38 Reineke kernel: sio6: <Moxa Technologies, Smartio C104H/PCI> on puc0
> Apr 30 10:13:38 Reineke kernel: sio6: type 16550A
> Apr 30 10:13:38 Reineke kernel: sio6: unable to activate interrupt in fast mode - using normal mode
> Apr 30 10:13:38 Reineke kernel: sio7: <Moxa Technologies, Smartio C104H/PCI> on puc0
> Apr 30 10:13:38 Reineke kernel: sio7: type 16550A
> Apr 30 10:13:38 Reineke kernel: sio7: unable to activate interrupt in fast mode - using normal mode
>
> 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.

Not using a fast interrupt handler may cause occasional silo overflows,
but shouldn't cause many.  The problem is mostly elsewhere (Giant locking
for too long), but siointr() shouldn't use Giant locking.  Try the following
patch if you still have shared interrupts:

%%%
Index: sio.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/sio/sio.c,v
retrieving revision 1.427
diff -u -2 -r1.427 sio.c
--- sio.c	7 Apr 2004 21:56:20 -0000	1.427
+++ sio.c	21 Apr 2004 14:20:17 -0000
_at__at_ -1162,5 +1302,6 _at__at_
 		if (ret) {
 			ret = BUS_SETUP_INTR(device_get_parent(dev), dev,
-					     com->irqres, INTR_TYPE_TTY,
+					     com->irqres,
+					     INTR_TYPE_TTY | INTR_MPSAFE,
 					     siointr, com, &com->cookie);
 			if (ret == 0)
%%%

I don't expect this to fix your problem.

> 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?

Configuring APIC (and ACPI if necessary for APIC to work) in both the
BIOS and FreeBSD is good for minimising shared interrupts.  You seem
to already have APIC (non-APIC interrupt numbers only go up to 15, but
you have #19).

OTOH, using the APIC may cause problems (interrupt storms), especially
for interrupt numbers > 15.  FreeBSD now has interrupt storm avoidance
to prevent storms from making the whole system unusable, but interrupt
storm avoidance for irq19  would cause your problem.  It rate-limits
the interrupt to 10Hz, but even low speeds like 19200 require much
more than that even on buffered UARTs:

    19200 bps = 1920 cps = at least 1920/16 = 120 interrupts/second

Here 16 is the input fifo size for the usual case of a 16550A UART.
Use systat -v to see the transient interrupt rate.

Bruce