Brian McGovern <[EMAIL PROTECTED]> wrote:
>However, when I start running data, I get silo overflows.
At which end? What else is the box getting SILO overflows doing? PIO
access to disks or network cards is good for disrupting interrupt
latencies. PLIP is virtually guaranteed to disrupt anything that
cares about interrupt latencies. Anything very fast on the ISA bus is
also likely to clag the system (simply because the ISA bus is sooo
slow).
Mike Smith <[EMAIL PROTECTED]> wrote:
> interrupt
>response time on your system is sufficiently poor that the time between
>the interrupt trigger at either 8 or 14 (I forget) characters in the
>FIFO
This can be configured in the UART. The driver switches between two
FIFO levels depending on speed (look at the FIFO_RX_... macros), but
I'm not sure of the absolute levels. You could try reducing the trigger
level (this should make the SILO overflows go away, but at the cost of
more interrupts).
>In order to debug this, you will need to use a logic analyser to trap
>the case where the interrupt is not handled quickly enough,
A slightly less invasive method, that will probably give you some
clues, is to instrument the hard interrupt entry points (defined via
INTR() in i386/isa/icu_vector.s or i386/isa/apic_vector.s), as well
as the siointr() function.
Some background: FreeBSD (should) only disable interrupts for very
short periods. Due to the (lack of) speed accessing the ICUs, the SPL
levels are held in software rather than in the ICU. This means that
an interrupt arrives in the kernel fairly quickly after it's raised in
hardware. The kernel checks the SPL mask to determine whether the
interrupt can be treated immediately. If not, it sets a flag and calls
the interrupt handler when the SPL level is dropped.
You could add code to check the time (eg by reading the TSC) and SPL
mask on interrupt and then check the time when siointr in invoked.
If the time is excessive, the SPL mask will give you some idea of what
was in progress.
Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
