Date: Sun, 2 May 2004 19:52:19 +0200 From: Burkard Meyendriesch <bm@malepartus.de> To: Bruce Evans <bde@zeta.org.au> Cc: atkin901@yahoo.com Subject: Re: sio: lots of silo overflows on Asus K8V with Moxa Smartio C104H/PCI solved Message-ID: <20040502195219.21874618.bm@malepartus.de> In-Reply-To: <20040501212314.N20783@gamplex.bde.org> References: <20040426111754.38a855c4.bm@malepartus.de> <20040426233925.Y5300@gamplex.bde.org> <20040430102504.477152ce.bm@malepartus.de> <c6u3nd$f8q$1@sea.gmane.org> <20040501102705.7a7ec726.bm@malepartus.de> <20040501212314.N20783@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 1 May 2004 21:41:27 +1000 (EST) Bruce Evans wrote:
> ...
> 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.
>
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?
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
May 2 16:09:34 Reineke kernel: sio5: <Moxa Technologies, Smartio C104H/PCI> on puc0
May 2 16:09:34 Reineke kernel: sio5: type 16550A
May 2 16:09:34 Reineke kernel: sio6: <Moxa Technologies, Smartio C104H/PCI> on puc0
May 2 16:09:34 Reineke kernel: sio6: type 16550A
May 2 16:09:34 Reineke kernel: sio7: <Moxa Technologies, Smartio C104H/PCI> on puc0
May 2 16:09:34 Reineke kernel: sio7: 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!
> > 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.
Burkard
--
Burkard Meyendriesch
Stevern 2
D-48301 Nottuln
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040502195219.21874618.bm>