From owner-freebsd-current@FreeBSD.ORG Sun May 2 22:00:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 218F116A4CE for ; Sun, 2 May 2004 22:00:22 -0700 (PDT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3909843D1D for ; Sun, 2 May 2004 22:00:21 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i4350J5v021892; Mon, 3 May 2004 15:00:19 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i4350HI2032371; Mon, 3 May 2004 15:00:18 +1000 Date: Mon, 3 May 2004 15:00:15 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Burkard Meyendriesch In-Reply-To: <20040502195219.21874618.bm@malepartus.de> Message-ID: <20040503145149.R3992@gamplex.bde.org> References: <20040426111754.38a855c4.bm@malepartus.de> <20040426233925.Y5300@gamplex.bde.org> <20040501212314.N20783@gamplex.bde.org> <20040502195219.21874618.bm@malepartus.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: atkin901@yahoo.com Subject: Re: sio: lots of silo overflows on Asus K8V with Moxa Smartio C104H/PCI solved X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 05:00:22 -0000 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 > > @@ -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. > > > 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: 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: 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