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

From: Bruce Evans <bde_at_zeta.org.au>
Date: Mon, 3 May 2004 15:00:15 +1000 (EST)
On Sun, 2 May 2004, Burkard Meyendriesch wrote:

> On Sat, 1 May 2004 21:41:27 +1000 (EST) Bruce Evans wrote:
> > ...
> > %%%
> > 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
> > _at__at_ -1164,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_CLOCK | INTR_MPSAFE,
> >  					     siointr, com, &com->cookie);
> >  			if (ret == 0)
> > %%%
> >
> > This is a superset of the previous patch.
> >
> I applied your patch to version 1.428 of sio.c of my actual source
> tree. The compiler complains:
>
> /usr/src/sys/dev/sio/sio.c: In function `sioattach':
> /usr/src/sys/dev/sio/sio.c:1167: error: `INTR_TYPE_CLOCK' undeclared (first use in this function)
> /usr/src/sys/dev/sio/sio.c:1167: error: (Each undeclared identifier is reported only once
> /usr/src/sys/dev/sio/sio.c:1167: error: for each function it appears in.)
> *** Error code 1
>
> I grep'ed the complete source tree for INTR_TYPE_CLOCK but couldn't
> find it. Did you mean INTR_TYPE_CLK out of /usr/src/sys/sys/bus.h?

Yes.

>
> I tried INTR_TYPE_CLK. The boot message is now:
>
> May  2 16:09:34 Reineke kernel: puc0: <Moxa Technologies, Smartio C104H/PCI> port 0xa000-0xa00f,0xa400-0xa43f,0xa800-0xa87f irq 19 at device 14.0 on pci0
> May  2 16:09:34 Reineke kernel: puc0: Reserved 0x40 bytes for rid 0x18 type 4 at 0xa400
> May  2 16:09:34 Reineke kernel: sio4: <Moxa Technologies, Smartio C104H/PCI> on puc0
> May  2 16:09:34 Reineke kernel: sio4: type 16550A
> ...
>
> I made a complete backup of my Palm Tungsten T3. systat -v showed
> me a sustained interrupt rate of 1400 ints/s on puc while iostat 1
> showed reasonable 11000 chars of input/s at 115200 bps. The Palm
> backup took about 58 minutes and produced absolutely NO silo
> overflow. The problem is obviously solved . . .
>
> Thank you!

You need to turn PUC_FASTINTR back off to test the patch.

> > > Btw, "device apic" doesn't exist; did you mean "device acpi"?
> >
> > They both exist in -current.  "device apic" is newer.
> >
> /usr/src/UPDATING explains "device apic" as a device for i386 kernels.
> For amd64 it doesn't seem to work.

Ah.  APIC hardware is standard for amd64 and PIC hardware should go away,
so "device apic" is standard and "device atpic" is optional for amd64.
This is the reverse of the standard and optional devices for i386 since
for i386, APIC hardware is not yet standard and PIC hardware is further
from going away.

Bruce
Received on Sun May 02 2004 - 20:00:22 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:52 UTC