kernel: sioxx: silo overflow with 8 ports pci MOXA cards

[Roberto Pereyra]

Thanks Bruce !!

Another question:

I have another server with a 2 port

I must use PUC_FASTINTR and COM_MULTIPORT options with it ?

I enable in the kernel the PUC_FASTINTR options but this dmesg continues:

My dmesg is:

sio4: <Dolphin Peripherals 4036> on puc0
sio4: type 16550A
sio4: unable to activate interrupt in fast mode - using normal mode
sio5: <Dolphin Peripherals 4036> on puc0
sio5: type 16550A
sio5: 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



Thanks again

roberto



On Thursday 20 January 2005 03:33, Bruce Evans wrote:
> 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 <Version 2.0> 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: <Moxa Technologies, C168H/PCI> on puc0
> > sio4: type 16550A
> > sio4: unable to activate interrupt in fast mode - using normal mode
> > sio5: <Moxa Technologies, C168H/PCI> on puc0
> > sio5: type 16550A
> > sio5: unable to activate interrupt in fast mode - using normal mode
> > sio6: <Moxa Technologies, C168H/PCI> on puc0
> > sio6: type 16550A
> > sio6: unable to activate interrupt in fast mode - using normal mode
> > sio7: <Moxa Technologies, C168H/PCI> on puc0
> > sio7: type 16550A
> > sio7: unable to activate interrupt in fast mode - using normal mode
> > sio8: <Moxa Technologies, C168H/PCI> on puc0
> > sio8: type 16550A
> > sio8: unable to activate interrupt in fast mode - using normal mode
> > sio9: <Moxa Technologies, C168H/PCI> on puc0
> > sio9: type 16550A
> > sio9: unable to activate interrupt in fast mode - using normal mode
> > sio10: <Moxa Technologies, C168H/PCI> on puc0
> > sio10: type 16550A
> > sio10: unable to activate interrupt in fast mode - using normal mode
> > sio11: <Moxa Technologies, C168H/PCI> 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
> _______________________________________________
> freebsd-hardware at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
> To unsubscribe, send any mail to "freebsd-hardware-unsubscribe at freebsd.org"