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

From: Bruce Evans (bde_at_zeta.org.au)
Date: 05/01/04

  • Next message: Burkard Meyendriesch: "Re: sio: lots of silo overflows on Asus K8V with Moxa Smartio C104H/PCI" 
    Date: Sat, 1 May 2004 14:38:19 +1000 (EST)
To: othermark <atkin901@yahoo.com>

    On Fri, 30 Apr 2004, othermark wrote:

    > Burkard Meyendriesch wrote:
    > > ...
    > > Meanwhile I plugged the Moxa board into another PCI slot of my motherboard
    > > and the conflict with the ata6 interrupt seems to be solved. The silo
    > > over- flows are still there.
    > >
    > > By the way: How should I set the BIOS parameters "PCPI 2.0 yes/no" and
    > > "ACPI APIC yes/no"? Do they have anything to do with the PCI interrupt
    > > behaviour?
    >
    > I had to enable APIC to get my puc supported card to work. W/o it the
    > interrupts were shared and I received a ton of silo overflows and lost data
    > on line.

    There must be bugs elsewhere for shared interrupts to cause lots of slo
    errors. Try my patch in other mail to avoid Giant lossage. I forgot
    to mention that a larger unwritten patch is also needed to fix sio's
    interrupt priority for the shared case (all tty interrupts get the low
    priority PI_TTYLOW, but most or all hardware ones should have priority
    PI_TTYHIGH, and drivers that prefer to use a fast interrupt should get
    priority higher than the current highest priority (PI_REALTIME).

    > so try the following in your kernel and rebuild
    >
    > options COM_MULTIPORT

    COM_MULTIPORT is only needed for old isa-ish multiport cards. It is
    not needed for cards supported by puc, and has large overheads so it
    shouldn't be used when not needed.

    > options PUC_FASTINTR

    This may be critical here. But don't use it if the port is actually
    shared with a device whose driver doesn't support fast interrupts.
    Then it will either have no effect or will break the attachment of the
    other device, depending on which device is attached first.

    > device apic

    He must already have this to get irq19.

    "device apic" may also cause silo overflows. See my other reply.

    Bruce
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Burkard Meyendriesch: "Re: sio: lots of silo overflows on Asus K8V with Moxa Smartio C104H/PCI"

    Relevant Pages

    • RE: Interrupt Priority
      ... Priority Among Simultaneous Exceptions and Interrupts ... Code Breakpoint Fault ... Faults from Fetching Next Instruction ...
      (microsoft.public.win32.programmer.kernel)
    • Re: Interrupt Priority
      ... Priority Among Simultaneous Exceptions and Interrupts ... Code Breakpoint Fault ... Faults from Fetching Next Instruction ...
      (microsoft.public.win32.programmer.kernel)
    • Re: [RFC][PATCH] irq: remove IRQF_DISABLED
      ... The "irq's disabled fastpath" thing has been there since pretty much day ... allowing higher priority interrupts to "preempt" ... lower priority ones, which this would effectively render useless. ... The problems with enabling irqs in hardirq handlers are that you get ...
      (Linux-Kernel)
    • Re: Data corruption during read on VIA vt8235
      ... >> Also if i copy big file through network (ethernet), ... lot of interrupts) is also important? ... # Loadable module support ...
      (Linux-Kernel)
    • Re: Linux serial port dropping bytes
      ... Changing ISR priority isn't going to make any difference. ... It only determines which of two pending interrupts get ... preempt lower priority ones. ...
      (comp.arch.embedded)