From owner-freebsd-hardware@FreeBSD.ORG Thu Jan 20 06:34:21 2005 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 651F216A4CE for ; Thu, 20 Jan 2005 06:34:21 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCF9943D1F for ; Thu, 20 Jan 2005 06:34:20 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j0K6Y1A6020131; Thu, 20 Jan 2005 17:34:01 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j0K6Xwj9010487; Thu, 20 Jan 2005 17:33:59 +1100 Date: Thu, 20 Jan 2005 17:33:58 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Roberto Pereyra In-Reply-To: <200501191449.13646.netbsd@contenidosonline.com.ar> Message-ID: <20050120171850.Q33587@delplex.bde.org> References: <200501191449.13646.netbsd@contenidosonline.com.ar> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hardware@FreeBSD.org Subject: Re: kernel: sioxx: silo overflow with 8 ports pci MOXA cards X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2005 06:34:21 -0000 On Wed, 19 Jan 2005, Roberto Pereyra wrote: > I have a 8 port pci Moxa C168U/PCI and use it like ppp server (with mgetty and > radius support). > > The server not works well because I have many "sio overflow" errors. The modem > drop the link or when the link is active (some minutes later) the link don't > send packets and drop. Large numbers of ports might cause this problem under versions of FreeBSD newer than FreeBSD-4, due to poor interrupt latency in these versions. However, "large" is hopefully more than 8. > Many times the modems not answer the call. > > Can anybody help me ? (excuse my english) > > My system is Freebsd 5.2 RELEASE > > My kernel is GENERIC plus this: > > # Serial (COM) ports > device sio # 8250, 16[45]50 based serial ports > options COM_MULTIPORT > device puc COM_MULTIPORT is not needed for puc devices. Using it when it is not needed (for other devices) just increases interrupt latency and reduces efficiency. (The driver doesn't handle mixtures of devices (with only some devices needing it) very well.) > My dmesg show: > > ioapic0 irqs 0-23 on motherboard > pcibios: BIOS version 2.10 > usb0: USB revision 1.0 > usb1: USB revision 1.0 > usb2: USB revision 1.0 > sio4: on puc0 > sio4: type 16550A > sio4: unable to activate interrupt in fast mode - using normal mode > sio5: on puc0 > sio5: type 16550A > sio5: unable to activate interrupt in fast mode - using normal mode > sio6: on puc0 > sio6: type 16550A > sio6: unable to activate interrupt in fast mode - using normal mode > sio7: on puc0 > sio7: type 16550A > sio7: unable to activate interrupt in fast mode - using normal mode > sio8: on puc0 > sio8: type 16550A > sio8: unable to activate interrupt in fast mode - using normal mode > sio9: on puc0 > sio9: type 16550A > sio9: unable to activate interrupt in fast mode - using normal mode > sio10: on puc0 > sio10: type 16550A > sio10: unable to activate interrupt in fast mode - using normal mode > sio11: on puc0 > sio11: type 16550A > sio11: unable to activate interrupt in fast mode - using normal mode > sio0 port 0x3f8-0x3ff irq 4 on acpi0 > sio0: type 16550A > sio1 port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A Try using PUC_FASTINTR to reduce interrupt latency. This may require juggling irqs so that the puc interrupt is not shared (hopefully not since apic mode is used). This is not the default because if the interrupt ends up shared then it may do more than just fail to activate the interrupt in fast mode as above -- it may break other devices that want the interrupt in normal mode, depending on whether it is activated in fast mode first. Bryce