>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).
>
Actually, the box with the silo overflows is doing 'not much'. Things like
sendmail and the other daemons are running (no net connection, tho, so I know
nothing is coming in/out), but otherwise, its a login, a copy of PPP, the
clock tick interrupts, and the sio interrupts and corresponding network
processing. I think it reports an average of 99.9% idle (the occational "blip"
on the stats).
>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
>
My short term "punt" is to use a desktop system. If I keep seeing the problem
there, I'll debug it some more. If it "goes away", I'll know it was the laptop
being quirky.
-Brian
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
