Date: Fri, 20 Aug 1999 09:22:06 -0400 From: Brian McGovern <bmcgover@cisco.com> To: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> Cc: hackers@FreeBSD.ORG Message-ID: <199908201322.JAA01890@bmcgover-pc.cisco.com>
next in thread | raw e-mail | index | archive | help
>Brian McGovern <bmcgover@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 <mike@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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908201322.JAA01890>