From owner-freebsd-hackers Thu Aug 19 20: 6:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 4549114DA0 for ; Thu, 19 Aug 1999 20:06:43 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40344>; Fri, 20 Aug 1999 12:45:07 +1000 Date: Fri, 20 Aug 1999 13:05:00 +1000 From: Peter Jeremy Subject: Re: sio doesn't do HW flow correctly?!? In-reply-to: To: hackers@FreeBSD.ORG Cc: bmcgover@cisco.com Message-Id: <99Aug20.124507est.40344@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian McGovern 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 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message