From owner-freebsd-hackers Fri Aug 20 6:22: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (Postfix) with ESMTP id 9096F14BE5 for ; Fri, 20 Aug 1999 06:22:07 -0700 (PDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA01889; Fri, 20 Aug 1999 09:22:06 -0400 (EDT) Received: from bmcgover-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.9.3/8.9.3) with ESMTP id JAA01890; Fri, 20 Aug 1999 09:22:06 -0400 (EDT) (envelope-from bmcgover@bmcgover-pc.cisco.com) Message-Id: <199908201322.JAA01890@bmcgover-pc.cisco.com> To: Peter Jeremy Cc: hackers@FreeBSD.ORG Date: Fri, 20 Aug 1999 09:22:06 -0400 From: Brian McGovern 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). > 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 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