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

[Bruce Evans]

On Sat, 1 May 2004, Burkard Meyendriesch wrote:

> On Fri, 30 Apr 2004 10:51:41 -0700 othermark wrote:
> ...
> > so try the following in your kernel and rebuild
> >
> > options COM_MULTIPORT
> > options PUC_FASTINTR
> >
> > device apic
> >
> Thanks for the hint, this solves my problem. I now have a constant
> char input flow rate of about 11000 chars/s at 115200 bps. This
> makes an average interupt rate of 1400 ints/s, so each interrupt
> service gets about 8 input chars of the silo. With a 16[45]50 silo

Oops, I used a factor of 14 in some other calculations.  Someone
reduced the fifo trigger level from 14 (2 below the top) to 8.  If
the interrupt latency is significantly less than 1 character time,
then the interrupt handler will always see precisely 8 characters
of input per receiver interrupt for sustained input.  Conversely,
we can determine whether there is significant latency from very
careful measurements of the number of characters per receiver
interrupt.

> size of 16 chars this seems to be a reasonable rate. All the silo
> overflow warnings disappeared.

So there must be something holding Giant for too long, and if my other
patch doesn't help then there must also be a thread with priority
higher than PI_TTYLOW that runs for too long.  This doesn't seem to
be much of a problem in my local configurations, so you can test fixes
and workarounds for it better than me.  Try the following untested
hack to get higher priority than most threads:

%%%
Index: sio.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/sio/sio.c,v
retrieving revision 1.428
diff -u -2 -r1.428 sio.c
--- sio.c	30 Apr 2004 21:16:52 -0000	1.428
+++ sio.c	1 May 2004 11:29:44 -0000
@@ -1164,5 +1302,6 @@
 		if (ret) {
 			ret = BUS_SETUP_INTR(device_get_parent(dev), dev,
-					     com->irqres, INTR_TYPE_TTY,
+					     com->irqres,
+					     INTR_TYPE_CLOCK | INTR_MPSAFE,
 					     siointr, com, &com->cookie);
 			if (ret == 0)
%%%

This is a superset of the previous patch.

> Btw, "device apic" doesn't exist; did you mean "device acpi"?

They both exist in -current.  "device apic" is newer.

Bruce