From owner-freebsd-hackers Tue Aug 13 17:49:56 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA23782 for hackers-outgoing; Tue, 13 Aug 1996 17:49:56 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA23767; Tue, 13 Aug 1996 17:49:50 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id KAA27572; Wed, 14 Aug 1996 10:36:30 +0930 From: Michael Smith Message-Id: <199608140106.KAA27572@genesis.atrad.adelaide.edu.au> Subject: Re: sio issues (silo overflows on a pentium, locked in ttywait, etc...) To: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) Date: Wed, 14 Aug 1996 10:36:29 +0930 (CST) Cc: freebsd-hackers@freefall.freebsd.org, lakes!rivers@freefall.freebsd.org In-Reply-To: <199608132036.QAA02107@lakes> from "Thomas David Rivers" at Aug 13, 96 04:36:03 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Thomas David Rivers stands accused of saying: > > However, I'm rather distressed to see: > > sio0: 1 more silo overflow (total n) > > messages popping out on VTY-2. This is with a 19200 connection, > the sending machine (of course, not experiencing any overflows) > is a 486dx-66. The receiving machine is a Pentium 75, with 16550a > uarts! This is a direct connection through a NULL modem with > brand new cables, with '-h' specified on both slattach's, so rts/cts > is being used... Just FYI, your P75 almost certainly doesn't have 16550A's. What you probably have is a blob from UMC or SMC or Winbond or someone like that that tries to emulate the PC16550 (note the correct part number folks). The 'correctness' of these emulations has been done to death around here; suffice to say that there are a number of possible causes for your problem : - There is a device driver you're using that keeps interrupts turned off for long enough for the sio driver to respond too late. General consensus has it that this is fairly unlikely. - Your UARTs are failing to generate FIFO trigger-level interrupts, or these interrupts are being lost by your hardware. 'silo overflow' errors are symptomatic of delayed or missed interrupts or faulty hardware. They are not (generally) symptomatic of software faults. > - Dave Rivers - -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[