Brian McGovern <bmcgo...@cisco.com> 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 <m...@smith.net.au> 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
